Comments for The Shape of Code

Comment on Relative spacing of operands affects perception of operator precedence by jduck

jduck — Mon, 23 Jan 2012 01:13:44 +0000

I tried Russ’s tool as well and found that some simple regular expressions returned no results despite the same expression have tons of results using regular grep. You may want to double-check your results using grep =)

Comment on Learning R as a language by Derek-Jones

Derek-Jones — Wed, 30 Nov 2011 13:29:05 +0000

@adamo What language feature does S have that ties it to statistics? Both environments contain packages of functions from the statistical domain and the R language provides the means to glue these together into something useful. R could just as well glue together functions from other application domains.

Comment on Learning R as a language by adamo

adamo — Wed, 30 Nov 2011 10:03:41 +0000

Well the specific language feature that ties R to statistics is its relationship to the S language

Comment on Compiler writing in the next decade by The Shape of Code » Compiling to reduce the impact of soft errors on program output

Mon, 07 Nov 2011 21:08:51 +0000

[...] for writers of optimizers to target, finding code sequences that minimise power consumption (I previously listed this as a major growth area in the next decade). Radiation (e.g., from cosmic rays) can cause a memory [...]

Comment on Empirical software engineering is five years old by The Shape of Code » Predictive Modeling: 15th COW workshop

The Shape of Code » Predictive Modeling: 15th COW workshop — Wed, 26 Oct 2011 17:48:28 +0000

[...] delay (e.g., 1 year) in implementing a requested feature. I have previously written about empirical software engineering only being a few years old and this research is a great example of how whole new areas of research are being opened up by the [...]

Comment on A change of guard in the C standard’s world? by The Shape of Code » What I know of Dennis Ritchie’s involvement with C

Thu, 13 Oct 2011 22:54:28 +0000

[...] the modern C world may not be affected by his passing, his ability to find simple solutions to complicated [...]

Comment on Memory capacity and commercial compiler development by Derek-Jones

Derek-Jones — Mon, 10 Oct 2011 07:19:09 +0000

@Larry O’Brien You are right that in the MS-DOS/Windows world it was the GUI and to some extent brand awareness rather than the quality of the generated code that drove many sales. Neither Borland or Microsoft were renowned for the quality of their code generation, with Microsoft being the most hyped and lowest code quality. As I recall Watcom were considered to be the optimizing leaders back then (now available as open source), a crown probably worn by Intel these days. I think what won it for Microsoft was longevity. At some point they made the decision that a C++ compiler was part of their core developer mindshare that had to be supported. Profits, is any, on product sales were a rounding error compared to Windows and Office. Had Borland or any other company looked like having significant developer mind share Microsoft would have dropped prices to gain market share (even though other vendors bent over backwards to offer Microsoft compatibility, something that Microsoft sometimes did not have had with previous versions of its own compiler). The original Borland compiler was written by an individual, Bob Jervis and I believe that Microsoft's was a team effort.

Comment on Memory capacity and commercial compiler development by Larry O'Brien

Larry O'Brien — Mon, 10 Oct 2011 02:18:32 +0000

I have a different take. We used to review all the C compilers at “Computer Language” and we were pretty close to the action. I think the battle between Borland and Microsoft, which was primarily about the quality of the IDEs, not the compiler toolchain, dominated the industry, hurting companies such as Zortech and Watcom. Then Borland stumbled terribly switching to Windows giving Microsoft a few years of uncontested market domination. MS delivered “good enough” tools and a low-cost IDE, starving out the few remaining C vendors. Those that survived concentrated on niche and embedded markets, where some continue to make a living, but the golden days of C vendors was over. In other words, I don’t think it was technology directly related to compilers but industry trends (GUIs, marketing, MS’ decisions vis a vis “co-opetition” with 3rd party vendors) and contingencies (Windows 3, the rise of OOP, recession).

Comment on Memory capacity and commercial compiler development by Greg Hewgill

Greg Hewgill — Sun, 09 Oct 2011 18:55:24 +0000

At Borland around the early 90s, the linker was implemented and maintained by a very talented woman programmer. Unfortunately I’ve forgotten her name, and while this was a linker and not a compiler, it was still part of the toolchain.

I didn’t work for Borland, but I spent a week at their office beating up the beta version of whatever the “next” version of their C++ IDE was at the time. I recall the linker being rock solid.

Comment on Memory capacity and commercial compiler development by Derek-Jones

Derek-Jones — Sun, 09 Oct 2011 01:58:48 +0000

@Ken
It is certainly possible for one person to bolt a new language front-end onto gcc/llvm and get high quality code out. For the same amount of work that person could generate simple assembler for some processor (i.e., not a lot of effort difference targeting gcc/llvm intermediate code or unoptimized assembler).

Some languages contain so much/complex semantics (e.g., Ada, C++) that I doubt anybody could do a complete front-end in 12-18 months.

I suspect the reason iPhone/Android so much app development is done by so individuals is that the economics don’t support larger teams. Most games were originally written by individuals, but once the money started to roll in team size soon mushroomed.