This is the final part of Type Systems Demystified which explores strong typing and type safety issues. It is a multi-language and comparative approach using Perl,C,C# and VB.net with a strong emphasis on Perl Link at i-Programmer, Strong Typing
I wanted to take a look on printing Unicode on the windows console by using the Win32 api and also check how is done in other languages, rather than directly from Perl which hides a lot of details Problems when wanting to print to the console : 1.The windows console uses an internal buffer that can mangle output 2.Invoking the console using the Unicode switch (cmd.exe /u) does not have an effect 3.Windows supports UTF-16 inherently, not utf8 4.Documentation on Unicode and the console is hard to find.MSDN library, as usual, is a labyrinth with no beginning and end where you can loose track easily The need arose when I needed to print an old style dos box using the cp437 box drawing characters on the console using their Unicode code points rather than their ASCII representation. The output was mangled/overlapped Take a look at this pictorial output to get a clear view of the problem The code that generated the incorrect result is : #unicode_box_incorrect.pl use Win32
Part 1 of Type Systems Demystifed was released. It explores dynamic and static typing. Link: Type Systems Demystifed Description: "This article is intended to help to someone who has a dynamic language background and wants to jump into the .NET platform, someone with VB.NET experience that wants to know how things work in C#, the C# programmer interested in dynamic programming, and any programmer who wants to know how type systems work."
Part 2 of Type Systems Demystifed was released. It explores weak and strong typing. Link: Weakly typed languages Description: "Weakly typed languages In Part 1 of this series we explored and compared the static and dynamic systems. Now we are going to focus on weak and strong typing and discover once more that the boundaries (which languages are considered strong and which weak) are not clearly defined."
this : Plain text ASCII report (plain.jpg) into this : PostScript report (postscript.jpg) How things work at the moment: PC's with Windows OS run terminal emulators which connect to Unix/Linux servers. When the ABF application generates a report its output is dumped on disc as a plain text file which is subsequently send to a network or local printer. When local printing is required (the printer is attached locally to the PC running the emulator) then the emulator opens a direct connection to the local printer port by using special escapes (called transparent ot pass-thru printing) and then forwards the plain text file to it. In either case the file is forwarded to the printer in RAW format, bypassing any printer drivers and thus is printed as-is. The same process holds also true for reports generated by OpenRoad on Windows The disadvandes of this approach are : (1). although sent in RAW format, the interpretation lies on the printer at hand; for example some print
A nice presentation on Eweek summing up Perl's past, present and future. Coupled with Tim Bunce’s Perl Myths , demonstrate that not only Perl was never dead but also that ,at milestones throughout time, gets rejuvenated