The Technology Vent and Rant Thread

[Bilbo1967]

Nothing wrong with COBOL; the only programming language I ever learned (and I wasn't very good at it)

[Katsunami]

Originally Posted by BetterRed

But she left IT to study law, is now an M&A specialist at a big merchant bank, she'll retire soon - with lots of gold in her sack

In retrospect, I should have studied law as well.

IT may offer lots of jobs, but it seems they're only for a select few under-24 whizzkids that are into all of the very latest fads or something. They'll ram out a project, then leave, and leave someone else to maintain it for 10 years (or to start over after it turns out to be unmanageable or the fad changes).

Been there, done that... as the under-24 whizzkid, and as the one maintaining such a project.

[Pablo]

Originally Posted by Bilbo1967

Nothing wrong with COBOL; the only programming language I ever learned (and I wasn't very good at it)

In my time I studied Basic, Pascal, Fortran, Cobol, C, C++ and the glorious Zilog Z80 machine code/assembly language, and had great fun with all of them, but only once, when I was 19, I was (briefly) able to make money out of all this knowledge and it was with COBOL...

[Bilbo1967]

Originally Posted by Pablo

In my time I studied Basic, Pascal, Fortran, Cobol, C, C++ and the glorious Zilog Z80 machine code/assembly language, and had great fun with all of them, but only once, when I was 19, I was (briefly) able to make money out of all this knowledge and it was with COBOL...

I know plenty of people who still make a decent living from COBOL programming.

[Pablo]

Originally Posted by Bilbo1967

I know plenty of people who still make a decent living from COBOL programming.

Good for them! I'm in a very different (and rather dull) sort of programming these days (industrial automation).

[DMcCunney]

Not a rant, but more of an eye roll.

One of the applications I have here is Pandoc. Pandoc is a document format converter, written in the functional language Haskell, and can convert most document formats to most other document formats. It's cross-platform, with builds for Windows, Linux, OS/X, and BSD, and can be built from source if a binary doesn't exist.

A poster on the Pandoc mailing list was trying and failing to call the Windows executable of Pandoc on Linux using Mono. Mono is the open source .NET implementation (and MS has open sourced .NET and is a major contributor to Mono), but Pandoc is not a .NET application. Why she thought that would work in the first place is one of life's little unsolved mysteries.

When I asked "Why are you trying to use the Windows version on Linux when a Linux version exists?", I was told she's writing a C# application that needs to call Pandoc, and thought it simplest to bundle the Windows EXE with her C# app.

I said "What you are trying to do can't work. If your program needs Pandoc as a dependency, the best thing to do is state that in the docs, with pointers to where to get it if it's not already on the user's system. Making sure dependencies are there is the user's problem." Her alternative would be trying to craft an install script for her application that would check if Pandoc was installed, and go fetch and install the proper version if it wasn't. I wouldn't want to try to do that...

She agreed that was the simplest solution and said thank you, but I was left shaking my head in wonder at needing to state what I thought was obvious.
______
Dennis

[DMcCunney]

Originally Posted by Katsunami

- In the beginning, programming languages didn't have enough structure, so Pascal was created, with very strict data typing.

Bear in mind that Pascal was created by Niklaus Wirth as a teaching language, to help programmers learn to craft algorithms. The original assumption was that the language would "compiled" on paper by the instructor when he graded student submissions. He hadn't intended it to be implemented on a machine. Because of that, basics like I/O were not defined in the original language specification.

Borland's Turbo Pascal (which was actually a Danish product Borland acquired and sold) created a generation of Pascal programmers with a cheap compiler that included IDE and debugger. But because Pascal didn't define things like I/O, the result was a small step above BASIC. Every vendor bundled BASIC on machines, and every version was customized for the hardware and what it could do. Cross-platform BASIC was essentially impossible, and a complete rewrite was needed to move the code to a different platform (assuming what your code did could be done on the new platform. Graphics, anyone?) Pascal wasn't a great deal better.

- Pascal didn't have enough power, so C was created for low level access and data casting from one type to another (Pascal later gained these things as well).

C was designed to be a systems programming language. The intent was a language with the high level control structures that made programmer's lives easier, but with enough power and efficiency that you didn't have to code in Assembler to get performance. It was also intended to be relatively easy to bring up on other architectures.

Dennis Ritchie was developing C at AT&T Bell Labs at the same time Ken Thompson and Brian Kernighan were developing Unix. Unix was being written in the version of Assembler offered by the DEC PDP machine they were using, but around Unix version 6, C was mature enough to rewrite Unix in it, with only about 10% of the low level code that talked to the hardware still in Assembler.

That portability became a major feature. The next step for Unix at AT&T was a Honeywell machine, and one of the selling points for Unix internally was that Unix with the full screen vi editor was a friendlier platform for the folks writing and submitting patent applications. (Vi? Friendly? Compared to line editors used from printing terminals like ed or SOS, Yes! Much friendlier!)

Then software got too large, with too many variables and functions splintered into too many files, so C++ was created to keep everything together in objects.

The object orientation was the point. And bear in mind, the earliest C++ implementation was on Unix in the form of cfront. Cfront parsed the C++ code and "compiled" it to standard C, which was compiled by cc to assembler, to be assembled to machine code by as, and linked into an executable binary by ld. C++ compilers that compiled to native code came rather later.

But people didn't want to do memory management, so you get languages like Java and C#.

And for good reason. Memory management is probably the single biggest source of bugs in code. The less programmers have to be aware of and handle those details, the better. (The machine can do a better job of keeping track of that stuff than you can, and if the tools exist to let it do so, you should use them.)

But Java and C# have a different basic objective. Java is "write once, run anywhere". Java code compiles to a tokenized binary that is executed by the Java Runtime Engine on the target system. Java code targets a virtual CPU implemented by the JRE, and the JRE abstracts away the differences between the virtual CPU and the real one.

The key to Java is that the object code is always the same, regardless of what it's compiled on. You should be able to compile Java on Windows, and run the result on Linux or OS/X, as long as a current JRE is installed. (I have IBM's open source Eclipse programmer's IDE here. It's written in Java. The same binary runs on Windows and Linux.)

C# is similar. C# code is executed by the .NET framework. Microsoft has made .NET open source, and MS engineers are major contributors to the Linux Mono project which was already implementing .NET on Linux. So C# code ought to also be portable to any place a .NET runtime exists.

Handling memory management for you has become a basic for current languages. Google's Go and Mozilla's Rust both try to do it. The question is how to implement garbage collection, reclaiming memory no longer in use, with the least possible impact on performance.
______
Dennis

[Terisa de morgan]

Originally Posted by DMcCunney

Handling memory management for you has become a basic for current languages. Google's Go and Mozilla's Rust both try to do it. The question is how to implement garbage collection, reclaiming memory no longer in use, with the least possible impact on performance.
______
Dennis

Yes, but that's a very main question if you try to do something professional.

[DMcCunney]

Originally Posted by Terisa de morgan

Yes, but that's a very main question if you try to do something professional.

How main the question is depends on what you are doing.

Hardware gets progressively smaller, faster, and cheaper. A chap elsewhere was reviewing a book on programming in the Python language. Python is technically a script language, compiling to a tokenized intermediate form that is executed by the language runtime. But as hardware gets smaller, faster, and cheaper, you reach a point where you can use something like Python where you previously had to compile to native code, because performance will be acceptable. The book in question was about programming in Python on the Raspberry Pi, an ARM based single board computer using an ARM cortex CPU that runs a custom version of Debian Linux called Raspbian which comes with Python as a built-in. The lowest end Raspberry Pi device is the Raspberry Pi Zero, which retails for $5 USD.

The efforts I've seen where the overhead of garbage collection becomes critical are in the embedded space with limited hardware resources and you need real-time performance where GC won't slow things down at a critical point.

Languages like Rust try to eliminate the need for GC, by guaranteeing allocated memory is automatically freed when everything that used that memory has released it, instead of requiring routines to look for stuff no longer used that can be freed.
______
Dennis

[Bilbo1967]

Originally Posted by Pablo

Good for them! I'm in a very different (and rather dull) sort of programming these days (industrial automation).

Sounds interesting actually

I make a living breaking software; I'm in software testing.

[DMcCunney]

Originally Posted by Bilbo1967

I make a living breaking software; I'm in software testing.

An old friend is a QA engineer. He said "You know what the difference is between a software developer and a QA engineer? The developer assumes the code will work. The QA engineer assumes the code will fail!".
______
Dennis

[Bilbo1967]

Originally Posted by DMcCunney

An old friend is a QA engineer. He said "You know what the difference is between a software developer and a QA engineer? The developer assumes the code will work. The QA engineer assumes the code will fail!.
______
Dennis

Sounds about right. And that's why developers need us

[Katsunami]

Originally Posted by DMcCunney

She agreed that was the simplest solution and said thank you, but I was left shaking my head in wonder at needing to state what I thought was obvious.

When writing a C# application to run under Mono, it basically is a Linux application, so it's indeed much easier to call a Linux executable of Pandoc. If you're going to run the Windows version, you'd need to run it on top of Wine.

(Does a Windows C#/.NET application still need Wine+Mono installed, or can it now just run on top of Mono, just like a Java application runs on top of the Java VM? Don't know... I never bothered trying to run Windows-stuff on Linux, but I do run the Cygwin commandline on Windows because I just know the Linux/Unix commandline _much_ better than the long-winded, overly verbose Powershell.)

[Katsunami]

Originally Posted by DMcCunney

Bear in mind that Pascal was created by Niklaus Wirth as a teaching language...

Pascal wasn't a great deal better.

I know Pascal was intended to be a teaching language.

However, Pascal WAS a great deal better than Basic, at least the Borland version. It was available for different platforms, and it had the BGI, or Borland Graphics Interface, which made graphics essentially cross-platform. It also had a framework called Turbo Vision, which is basically the MS-DOS-predecessor of the Visual Component Library (VCL) from Delphi. The designer of Turbo Vision and later the VCL tried to get the VCL included in Windows for years, but Microsoft wouldn't hear of it.

Then C# came out, and when I first used it in 2006, my reaction was:

"Man... this is like Delphi/VCL, but with C syntax!"

Sure enough, both the VCL and .NET were designed by the same man: Anders Hejlsberg. The VCL used either C++ (Borland C++ Builder) or Object Pascal (Delphi), and they later got combined within the same IDE.

Therefore...

(Object Pascal/C++ on top of VCL) == (VB/C#/etc on top of .NET)

C was designed to be a systems programming language.

I know, and if you need pure speed, C and C++ (which, on compiling, strips ALL of the syntactic sugar such as objects en such) are still unmatched. C and C++ compilers are so good nowadays that it's virtually impossible to write more efficient assembler code by hand.

The object orientation was the point. And bear in mind, the earliest C++ implementation was on Unix in the form of cfront. Cfront parsed the C++ code and "compiled" it to standard C, which was compiled by ccp to assembler, to be assembled to machine code by as, and linked into an executable binary by [i]ld[/d]. C++ compilers that compiled to native code came rather later.

To some extent, steps like these are still common in (for example) the GNU toolchain: compiling from one language to an intermediary, to object code, with assembler compiled by a different program, and then they're all linked together.

And for good reason. Memory management is probably the single biggest source of bugs in code. The less programmers have to be aware of and handle those details, the better. (The machine can do a better job of keeping track of that stuff than you can, and if the tools exist to let it do so, you should use them.)

Agreed. If there's one thing I don't miss from C and C++, it's memory management... but I DO miss strong typing when working in something like Javascript of PHP.

Strong typing, and enforcing variable declarations should be _mandatory_ in any language, because now, the biggest causes of bugs have moved from mishandling memory management, to typo's in variable and function names.

edit:
Anders Hejlsberg

Aaaaaaand.... there you have it, why TypeScript (the 'strongly typed Javascript') uses Pascal-style type syntax: this guy is the lead designer of that language. It seems that, apart from C/C++ (Ritchie, Kernighan, Thompson/Stroustrup), everything I've ever used with regard to programming was either designed, or heavily influenced by Hejlsberg.

I think he needs to be in the same hall of fame as Ritchie, Kernighan, Thompson and Stroustrup. They defined much of the computing environments and languages in the 1960's, 1970's and early 1980's, while Anders Hejlsberg defined most of the stuff from 1985 onwards. First it was Turbo Pascal which made a cheap and powerful compiler and IDE available to everyone (with the Borland Pascal version yet more powerful for professionals), and then Delphi was HUGE from 1995 up to 2004-5, with Delphi 7 and C++ Builder being the best IDE's ever created... IMHO. After 2004-5, .NET basically took over, but it was designed by the same man.

And now that development is moving towards more and more Javascript, taking it out of the browser with NodeJS and it not being fit for purpose anymore (apps are getting too large for a dynamic, untyped language), he is _again_ the lead designer of the next big thing.

[DMcCunney]

Originally Posted by Katsunami

When writing a C# application to run under Mono, it basically is a Linux application, so it's indeed much easier to call a Linux executable of Pandoc. If you're going to run the Windows version, you'd need to run it on top of Wine.

Yep.

(Does a Windows C#/.NET application still need Wine+Mono installed, or can it now just run on top of Mono, just like a Java application runs on top of the Java VM? Don't know...

AFAIK, you should be able to run a C# application on Linux with just Mono, since the .NET runtime Mono implements actually executes the code. The C# code should be portable. You shouldn't need Wine in the mix.

I never bothered trying to run Windows-stuff on Linux, but I do run the Cygwin command line on Windows because I just know the Linux/Unix command line _much_ better than the long-winded, overly verbose Powershell.)

I used to run Cygwin but got cured of it. (I also ran AT&T's U/Win environment, which was an attempt to do the same thing that Cygwin did, developed by Dr. David Korn, the author of the Unix Korn Shell.)

Cygwin is an attempt to port the Gnu Linux toolchain to Windows, particularly the GCC compiler suite. The Cygwin developers encapsulated a subset of the POSIX API in the Cygwin1.dll file. A lot of Linux code builds "out of the box" under Cygwin because it links against the Cygwin DLL and sees the *nix system calls it needs.

That's fine if you want to develop code that will run under Linux on Windows, because you can set GCC to cross-compile to a Linux target. But you pay a performance penalty compiling for Windows because some things in *nix don't exist in the Win32 API, like fork, and there is overhead in translating the code to something that can run.

In addition, the Cygwin environment from a command line is different from Windows.

Back in the MSDOS days, I ran a package called the MKS Toolkit. I had a Unix machine at home (an AT&T 3B1) before I got a PC running DOS, and I wanted DOS versions of Unix commands. The Toolkit implemented all of the Unix commands that made sense on a single-tasking, single user OS like DOS. In particular, it offered a full version of the vi editor, and an implementation of the Korn shell that had everything save asynchronous sub-processes, because DOS didn't do that.

I had the Toolkit installed in fullest Unix emulation mode. Installed that way, when DOS was booted, the boot shell was the Toolkit INIT.EXE program. Init ran and printed Login: on your screen. You entered a userid and optional password. The userid was checked against a Unix compatible /etc/passwd file, and if a match was found, it changed to whatever was specified as that user's home directory, and ran whatever was specified as that users shell.

I made use of this. I had IDs that ran the Toolkit Korn shell, the shareware 4DOS COMMAND.COM replacement, vanilla COMMAND.COM, and the DesqView multi-tasking GUI. Exit the shell, and control returned to INIT, which printer Login: again. I could change environments without rebooting. (I kept the setup when I moved to Wi3.X. The default shell for Win3.X was Program Manager, but you could change that in the SYSTEM.INI file. I had Toolkit IDs that ran Win3.X using alternate shells. Worked fine.)

But the MKS Korn shell used Unix style command lines, where / was the directory separator, and - was the option delimiter. DOS used \ and / for those. The Toolkit provided a SWITCH utility that could change DOS's idea of what those delimiters were, and once - was the option delimiter, you could use / or \ as the directory separator. Unfortunately, some DOS programs didn't look at what DOS thought those chars were, and hard-coded \ as directory separator and / as option delimiter, so I had to wrap them in Korn shell aliases to run SWITCH to reset things on entry and exit.

Windows retains DOS usage, the same problems affected Cygwin under Windows, and similar work-arounds were required.

These days, I run versions of the *nix commands compiled to use Windows runtimes instead of Cygwin. There are several variants available. The current set is part of Git for Windows, which includes the Git DVCS and the standard Gnu Linux commands, including the Bash shell.

And Win10's Creators Update includes an optional package. Developers at Canonical, Ltd, Ubuntu's parent, have created libraries that let you run Linux command line apps under Win10. The original version was Ubuntu specific, but it's been expanded to include Fedora and Open SUSE. I can run a Bash command line under Win10 and use apt-get to install Linux utilities for use under it. And you can apparently run at least some Linux GUI apps if you run a Windows based X-server, though I haven't tried to.) You have the same issue that you are in a different environment, and calling Windows stuff from the Linux subsystem and vice versa takes fiddling, but you can.
______
Dennis