Memory is expensive, and every character we could possibly ever want to use fits in eight bits, so of course strings are sequences of eight-bit characters.

A tree is the most obvious representation of a programming language within a compiler or interpreter, so of course a programming language which should allow manipulation of the language by mere users should use the textual form of its tree representation.

Programmers can make mistakes with complex language features so of course removing those features will prevent mistakes.

Sometimes writing fast programs requires low-level access to memory so of course you can write this new language just like you wrote its predecessor.

Portable programs can be useful so of course it's important that you never leave the comfortable confines of the virtual machine and standard library or image.

Beating Microsoft is essential to our success so of course we don't have time to think through the implications of our language's design.

Bad programs often have poor indentation so of course enforced indentation will make people write good programs.

Perl 1, 2, 3, and 4 were great replacements for awk, sed, and shell programs, so of course the everything-goes, loosey-goosey approach to strictness is the right default for Perl 5.

From this I conclude that language designers are as good at predicting the future as anyone else: not very.


It's difficult to make accurate assumptions in a future.

i.e. "640k of memory should be enough for anybody."

I'm always curious to see how programing languages evolve in 5/10 years... I'm not a language designer or guru, but more I'm a final consumer.

Now there are lot of things around growing, like social networks, mobile internet, GPS and geolocalization, touching interfaces, moving sensors/accelerometers, speech input/output... the cloud... the API-fication of internet...

That things where invented years ago, but now devices like tablets and mobiles (I'm not going to make publicity here) and other changes around the internet _users_ and "de facto standards" are changing lot of things around programing new applications.

I hope, that the future is not only html5+css3+JS with embedded video/SQL but there are good back-end (and system integration)technologies, that the future doesn't need eclipse or adobe * or o a OSX/MS license/IDE or other dinosaurs different than vi to start programing something.

In matrix the future was about a blue/red pill... we're fine while people doesn't loose the linux/unix "make it yourself" philosophy (as known as freedom).

When I need to make assumptions in my work (i.e. "estimate us the hardware/software needed to virtualize that data-center") I need to collect previous data, not only from hardware/software...

I need to know users/projects in course/future, data-center life status/functionality of non virtualizable elements (i.e. racks, KVMs, UPSs, network electronic, etc) and other factors (available money, etc...) so maybe that new programing language designers should open their mind to lot of things lot of times not related to language syntax or execution... _of course_? :-).

I'm glad to see HTML5 modules, and much more daily on CPAN "the alive".

I'm not very informed on Perl6 but I'm glad that people is playing to make innovation around programing, and that some changes are back-ported to our language (CPAN) that runs in our VM (Perl 5).

Here is my assumption: "Current Perl reality is wonderful, so _of course_ authors should go in the same line that the last 20 years (improving little things each day, improving big things some days, and sharing)" :)

Make accurate assumptions in a future... is always difficult.


P.S. I think Perl portability is great, comparable to netbsd in operative systems.

P.S. I think Perl portability is great, comparable to netbsd in operative systems.

That said about the perl interpreter, I've not experience about portability of perl code.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide



About this Entry

This page contains a single entry by chromatic published on June 17, 2010 1:55 PM.

Sometimes a Little Too Dynamic was the previous entry in this blog.

When Assembly Leaks Through is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by the Perl programming language

what is programming?