The Vent and Rant Thread

[Katsunami]

Originally Posted by DMcCunney

I do note from poking around elsewhere that Kovid seems to have an experimental port to C# in the works. Microsoft has officially made .NET open source and has been contributing to the Mono project that brings .NET to Linux. This provides C# under Linux as well, and OS/X.

C# may well be faster than Python, so it will be interesting to see this develop.

Porting calibre to C# basically means rewriting the entire program from scratch. That is not a menial task.

In C#, it would be faster however, because C# has a JIT compiler. It doesn't interpret; it compiles the code just before it runs, starting from MSIL and then caching the result. (MSIL = Microsoft Intermediate Language, which is what all .NET programs build into.)

[DMcCunney]

Originally Posted by Katsunami

Porting calibre to C# basically means rewriting the entire program from scratch. That is not a menial task.

Oh, certainly. I believe translation tools exist to help, but you are still looking at a rewrite, and Calibre is a massive application.

In C#, it would be faster however, because C# has a JIT compiler. It doesn't interpret; it compiles the code just before it runs, starting from MSIL and then caching the result. (MSIL = Microsoft Intermediate Language, which is what all .NET programs build into.)

Lots of things do JIT compilation now. Browsers, for instance, now do JIT on JavaScript, compiling to machine code before execution for the highest possible speed. (And Mozilla got embarrassed a while back because their previous JavaScript engine wasn't smart enough about it, and compiled to machine code in cases where it would have been faster to just interpret the JS instead of compiling. Their current script engine is a lot better about that.)

Python and Java are also intermediate languages, that compile to a tokenized binary that is executed by the language runtime. In the case of Java (and Python, I believe) the tokenized binary is always the same, regardless of where you compiled. Compilation is to a binary targeted at a virtual processor implemented by the language runtime, and the runtime abstracts away actual hardware differences. (I've seen Java code that benchmarks faster than the same function written in C++.) So you can do things like compile under Windows and run the result on a Mac.

C# does similar sorts of things. I don't think we're quite there yet, but with MS open sourcing .NET and contributing to the Linux Mono project, we are looking at C# also being a cross platform language, with programs written and compiled in it running anywhere there's a suitable runtime available.
______
Dennis

[Toxaris]

Originally Posted by DMcCunney

C# does similar sorts of things. I don't think we're quite there yet, but with MS open sourcing .NET and contributing to the Linux Mono project, we are looking at C# also being a cross platform language, with programs written and compiled in it running anywhere there's a suitable runtime available.

We are there yet to be honest. Mono is quite stable and MS has been contributing to it for quite a while. The newer and really fancy .Net functions are not yet into Mono, but most programs can run on Mono without much trouble. It is usually not the support in Mono that is the problem, but the programmer... For example hard-coding slashes instead of using DirectorySeperator and things like that. If you program smart, you can compile on Windows and run it on Linux/OSX. In fact, most of my programs run on Linux/OSX without me altering anything. There is one that won't run, but that is due to an external factor, not Mono.

I am looking forward to .Net Core, but it will not help ignorant programmers that hard code things.

[DMcCunney]

Originally Posted by Toxaris

We are there yet to be honest. Mono is quite stable and MS has been contributing to it for quite a while. The newer and really fancy .Net functions are not yet into Mono, but most programs can run on Mono without much trouble. It is usually not the support in Mono that is the problem, but the programmer... For example hard-coding slashes instead of using DirectorySeperator and things like that. If you program smart, you can compile on Windows and run it on Linux/OSX. In fact, most of my programs run on Linux/OSX without me altering anything. There is one that won't run, but that is due to an external factor, not Mono.

That is good news, and I'm delighted to hear it.

Any general idea of things that work in .NET under Windows, but don't yet work under Mono? What sort of constructs are problems?

I am looking forward to .Net Core, but it will not help ignorant programmers that hard code things.

Directory separators have been a bane of my existence for decades, and it's nice the language runtime has constructs you can use to let the runtime figure out the proper usage on the platform the code is running on and do the right thing.

Getting programmers to Do the Right Thing is beyond the reach of language designers.
______
Dennis

[Katsunami]

Originally Posted by DMcCunney

Directory separators have been a bane of my existence for decades, and it's nice the language runtime has constructs you can use to let the runtime figure out the proper usage on the platform the code is running on and do the right thing.

Getting programmers to Do the Right Thing is beyond the reach of language designers.

I've solved things like that ages ago, before languages abstracted that.

In the past I had a file, that had things in it such as:

DIRECTORY_SEPARATOR = /
CURRENCY_SYMBOL = fl.

And so on. I also had language files like that, and in some programming languages, I still work like that if they don't have the required abstraction, or the abstraction is more cumbersome than this method.

In some languages, I just included the file (such as in PHP, including 'constants.php"), while in other languages, I read it as if it was an INI-file.

Not perfect, but things like that did allow me to write a backend on a Windows webserver and then put it onto a Linux one afterward, with just a bit of reconfiguration.

[DMcCunney]

Originally Posted by Katsunami

I've solved things like that ages ago, before languages abstracted that.

In the past I had a file, that had things in it such as:

DIRECTORY_SEPARATOR = /
CURRENCY_SYMBOL = fl.

And so on. I also had language files like that, and in some programming languages, I still work like that if they don't have the required abstraction, or the abstraction is more cumbersome than this method.

In some languages, I just included the file (such as in PHP, including 'constants.php"), while in other languages, I read it as if it was an INI-file.

Not perfect, but things like that did allow me to write a backend on a Windows webserver and then put it onto a Linux one afterward, with just a bit of reconfiguration.

I've done analogous things.

One of the things I've had to do a fair bit of is moving stuff between Unix and Windows. Directory separators are one PITA. Differing EOL conventions are another.

In Unix, lines are terminated by a Line Feed character - ASCII 11. In Windows, lines are terminated by a Line Feed and a Carriage Return - ASCII 13. (And to make life complete, Mac OS "Classic" used only a CR.)

In one case, I had production reports generated on a Unix server that were sent in email to project managers. The reports were standard text files. They showed up as attachments to email in Outlook, and the PMs double clicked the attachment to read them. By default, Windows opened them in Notepad.

Notepad is stupid, and didn't grok the EOL convention. Because there was no CR at the end of the line along with the LF, you got a stair-step effect, where the next line appeared on a new line, but did not begin at the left margin.

I had to add a function to the script that handled the email to convert line endings to CRLF before sending the reports.

Way back when, I ran a package under MSDOS called the MKS Toolkit. The Toolkit provided MSDOS implementations of all of the Unix commands that made sense in a single-user, single tasking OS like DOS. The killer app for me was a complete version of the Unix Korn shell, with everything save asynchronous background processes.

Installed in fullest Unix compatibility mode, it could be hard to tell you weren't on a Unix machine when you were in the MKS Korn shell.

But the Toolkit used Unix directory separators and EOL conventions. It mostly worked, but some DOS programs I used got very confused, because they were hard coded to expect \ as a directory path separator and / as an option delimiter, even though there was an MSDOS function that would let you change that at the OS level.

I wound up writing wrapper functions that reset things to the DOS default before running the DOS programs, then set them back to the Toolkit default when the program exited.

I haven't had to do stuff like that in a while, and that makes me happy.
______
Dennis

[Toxaris]

I recently had a large discussion with a programmer who was writing commercial software. The data relies heavily on timestamps for several reasons (terms, auditing and more). Furthermore the application will be used internationally. The programmer was using system local time and used that time without timezone indicator. However, there is no way of telling what the location of the server is and what the system local time is. I tried to explain to him why he should use UTC with an offset as a base and then, for GUI purposes, translate that to the timezone of the user. He just wouldn't get it... Needless to say in the end I just ordered him to do it like I said and I have a suspicion his contract will not be renewed as this was not the first time something like this happened. I will explain that time with one word only... Unicode.

[Katsunami]

Originally Posted by DMcCunney

I haven't had to do stuff like that in a while, and that makes me happy.

Stuff like that got me INTO computers.

Nowadays, without having to know anything about how this low-level stuff works, and without having to use pointers, I'm sometimes more confused than ever.

"But I don't want Type X, and Type Y, and then having to typecast back and forth, I just want a block of exactly 8192 bytes, and I want to write whatever and where-ever I please!"

In the past, you could also do things like this:

int x = 300; // two bytes long (mostly, but not always :p)
byte *y = &x; // y is a pointer of byte, pointing to x

Now you could put a value in x, and then read back each byte separately by using *y or *(y + 1).

Not being able to do things like that in many languages irks me to no end, because it often requires me to write functions to extract data from a bunch of bytes.

[Katsunami]

Originally Posted by Toxaris

I recently had a large discussion with a programmer...

He just wouldn't get it...

Needless to say in the end I just ordered him to do it like I said and I have a suspicion his contract will not be renewed as this was not the first time something like this happened. I will explain that time with one word only... Unicode.

Stuff like this is not taught anymore in HBO schools (university of applied science). I can see it in (most) people who have finished HBO in the last 10 years or so. I think I was one of the last who still actually learned to account for things like that. (And even so I'm doing a master because I think I still think many things were missing from *my* education; I know / can do them, because I studied them or happened upon them myself, but 'officially', I *don't* know them, if you know what I mean.)

And you know what the irksome thing is? In most companies where I've worked, it's more like this:

Me: "But you have to use... and do... to take into account... otherwise... *%^&%^&*"
Manager: "Costs too much time. Just hard-code it."

It's one of the main reasons why I got to dislike most managers. Most of them only see "The project will take 4 weeks of extra time * so many employees = that cost", while ignoring that shit will hit the fan if one of the things I mentioned actually happens. THEN there will be a major code rewrite, which often takes longer, is harder to test (as you must make sure not to break other parts of the code), and thus much more expensive than doing it right from the start.

[CRussel]

Y'ah know, folks, this is not the computer programming/literacy thread. Just saying.

Thank you.

[Freeshadow]

I'm no coder and I understand what they speak about. So it can't be THAT bad. An usual job rant.
And yes bad Unicode or text file handling implementations DO epically suck job wise if you work with text.

[wodin]

Originally Posted by CRussel

Y'ah know, folks, this is not the computer programming/literacy thread. Just saying.

Thank you.

Yeah, what he said.

I got into computers through programming, mostly self taught; but over the years I've found IT management to be much more lucrative and any coding skills I once might have had have pretty much atrophied to nothing.

[Katsunami]

Originally Posted by wodin

Yeah, what he said.

I got into computers through programming, mostly self taught; but over the years I've found IT management to be much more lucrative and any coding skills I once might have had have pretty much atrophied to nothing.

Yeah, that's another rant on its own. IT management often pays so much more that in the Netherlands, we've been seeing classes and classes full of people who study "Management & IT" or "Corporate I(C)T." The result is that we have a bazillion people who know (or think to know) how to manage that X will get done, but nobody who can actually *DO* X.

Last time I've looked, Management & IT had become a useless education. If a company needs to get shit done (= an actual product must be created), being able to hire 800 managers is of no use if you can't find anyone with the knowledge to actually create the product.

[Cinisajoy]

Originally Posted by Katsunami

Yeah, that's another rant on its own. IT management often pays so much more that in the Netherlands, we've been seeing classes and classes full of people who study "Management & IT" or "Corporate I(C)T." The result is that we have a bazillion people who know (or think to know) how to manage that X will get done, but nobody who can actually *DO* X.

Last time I've looked, Management & IT had become a useless education. If a company needs to get shit done (= an actual product must be created), being able to hire 800 managers is of no use if you can't find anyone with the knowledge to actually create the product.

One of our local colleges offered IT classes. The non-joke was easy A classes. I only know of one person that didn't make an A in the classes and that was because she was strange.
She didn't do the work, would take stuff from other people's lives, totally exaggerated things (that one on occasion led to problems for others) and made things up.
Oh I don't mean physical stuff, I mean if you had lived somewhere she had lived there, she once said she had the same boyfriend as another friend, oh and she had a two year pregnancy that ended in a miscarriage (her sister had a baby).

[wodin]

Originally Posted by Katsunami

Yeah, that's another rant on its own. IT management often pays so much more that in the Netherlands, we've been seeing classes and classes full of people who study "Management & IT" or "Corporate I(C)T." The result is that we have a bazillion people who know (or think to know) how to manage that X will get done, but nobody who can actually *DO* X.

Last time I've looked, Management & IT had become a useless education. If a company needs to get shit done (= an actual product must be created), being able to hire 800 managers is of no use if you can't find anyone with the knowledge to actually create the product.

Yup, as an IT Project Manager, my mantra is "I'm NOT an engineer" (software or hardware or infrastructure or marketing or budgeting or any other aspect of the industry), and I must rely heavily on those who are. In PM parlance those folks are "resources", and without resources I'm hamstrung.

IT management is about knowing just enough about the resources to patch them together into a useful and profitable product.

So in the final analysis you need one PM and a host of Subject Matter Experts (SME), and the skills to be a PM can be approached from any of the various subjects, and while it can be taught in institutions that path will not normally provide the requisite experience.