an "old beard" ?

Posted Mar 27, 2008 10:17 UTC (Thu) by jschrod (subscriber, #1646)
In reply to: an "old beard" ? by tialaramex
Parent article: Striking gold in binutils

> By the time C++ was being invented we already knew that the challenge
> wasn't adding more expressiveness (though given a time machine maybe I'd
> add namespaces and possibly a weak "class" concept to C89), but delivering
> more maintainability. The author of this program has already expressed his
> doubts about the maintainability of his code.

If you read the article, this was not because he used C++. He was reluctant if other people
will understand his finite state automaton, that needs to be understood overall to see what
the code does. FSAs tend to distribute functionality to small pieces of code where the
connection is often not easily visible. Many programmers can't handle that properly.

an "old beard" ?

Posted Mar 27, 2008 12:10 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (3 responses)

I did read the article, and I agree that C++ doesn't inherently make his state transition
stuff harder to understand. But it also doesn't help. That's all. I guess there are languages
which would, but I don't know if they're also suitable for the low-down bit mangling the
linker does elsewhere.

finite state machines

Posted Mar 29, 2008 1:33 UTC (Sat) by man_ls (guest, #15091) [Link] (2 responses)

Not that I know of. Finite state machines are actually hard to code and read in any language, so your argument (C++ somehow made gold more difficult) sounds like a red herring to me.

Oddly enough, it seems this is an area where graphical programming should help: state diagrams (or flowcharts) can really help you understand a state machine. But apart from some of the new BPM tooling, which covers a similar but different problem space, that idea hasn't flown either.

finite state machines

Posted Mar 29, 2008 7:30 UTC (Sat) by salimma (subscriber, #34460) [Link] (1 responses)

FSMs are trivial in languages with tail-call optimization (Lisp et. al., ML, Haskell .. even
Lua!). It is true, though, that most of these languages are not geared towards low-level bit
manipulation.

C--, perhaps. It's a C-like language used by the Haskell team as their intermediate language,
a sort of souped-up assembler.

finite state machines

Posted Mar 29, 2008 12:39 UTC (Sat) by man_ls (guest, #15091) [Link]

Oops, you are right: FSMs are indeed easier to implement in those languages. My big mouth again.

They are still pretty hard to follow and understand. Which is of course the concern of the author of gold. But maybe even this can be alleviated with functional programming; on the 7th Antual ICFP Programming Contest functional languages were shown to be an order of magnitude better at writing input for FSMs than imperative languages. I'm not so sure any longer.

So thanks for the clarification, and please disregard my earlier uninformed comment about a red herring.