Linked by snydeq on Sun 11th Dec 2011 01:35 UTC
General Development Fatal Exception's Neil McAllister writes in favor of new programming languages given the difficulty of upgrading existing, popular languages. 'Whenever a new programming language is announced, a certain segment of the developer population always rolls its eyes and groans that we have quite enough to choose from already,' McAllister writes. 'But once a language reaches a certain tipping point of popularity, overhauling it to include support for new features, paradigms, and patterns is easier said than done.' PHP 6, Perl 6, Python 3, ECMAScript 4 -- 'the lesson from all of these examples is clear: Programming languages move slowly, and the more popular a language is, the slower it moves. It is far, far easier to create a new language from whole cloth than it is to convince the existing user base of a popular language to accept radical changes.'
Permalink for comment 499778
To read all comments associated with this story, please click here.
on the hardware/parallel side
by transputer_guy on Sun 11th Dec 2011 07:56 UTC
Member since:

I also believe that we are in need of newer languages for specific domains, but at the same time they need to be able to work with the current infrastructure so that the new language doesn't have to reinvent all the plumbing that current languages already do well. The new language can then be built quickly by adding a preprocessor or interpretive module to the tool mix just as the early C++ preproc did.

One example is to do math in Fortran and use F2C to merge the math code within a C system. Same with Matlab and others.

One weak area has always been concurrent programming of communicating processes over many processors or within hardware. When you model really large parallel systems, they look just like nested blocks of hardware logic where the processes might be software or hardware cells communicating with wires (hdl) or channels (occam/csp).

We can kind of hack around this with C++ classes like in System C which makes designing hardware really ugly. In the hardware field we already have Verilog and VHDL, for designing massively parallel systems but they don't really work well with C and cost big $ to use. The System C guys came along and said, you hardware guys can just use our C++ classes to model wires, events and so the hardware code would run in a free C simulation environment. What was not free was the tools to convert the SystemC description back to Verilog to make the hardware, money ruins it all.

I ended up writing my own primitive Verilog subset V2C that allows hardware logic to be written in almost pure Verilog and compile to C for cycle simulation and the same code could then go through normal hardware synthesis tools usually free for FPGAs, no $ at all.

Even to this day I don't think you can get this type of utility with out big bucks. I would like to have taken this further by combining subsets of Verilog and C+ to produce a smaller united language. In the Verilog syntax you describe the parallelism of logic blocks and signals and in the C syntax you write behavioral C functions to validate those blocks.

The first hardware description language I ever learnt for processor design was APL from the 60s and yet many old timers will know that was used for business software and likely just as incomprehensible.

Perhaps Go might be a useful tool for hardware guys since it has a far more natural syntax for describing block modules with multiple I/Os, still have to finish the tutorial.

just blabbering on

Reply Score: 3