User avatar
DavidS
Posts: 3280
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Tue Nov 22, 2016 10:17 pm

Heater wrote:ejolson,

From the outside it looks like the F-35 project has bitten off more than it can chew, not just from a software perspective.

Certainly big corporate software projects have been failing for decades. See Multics and Fred Brook's famous book "The Mythical Man Month". Heck I have worked on many a cancelled project. We never learn.
Yes indeed.
No idea about Epiphany. The Wayland developers maintain they are trying to remove cruft and shrink what was X11. I don't know.

C++ does indeed feel like a "grab bag of experimental features cobbled together by tinkerers". Reality is though that the C++ devs, the guys on the standards committee, are not tinkerers. They are seriously smart, experienced, guys from MS, Google, Apple, elsewhere.
I thought you said smart guys. Not tinkerers. :)

Though realy just because it is a standard, does not mean that is how it was designed. Things tend to be in standards because they are widely used already, look at how long C++ was around before there was a standard.

And if we look at the evolution (or is it devolution) of C++ we see what (once named C++) started as a very cohesive and reasonable language, then more "features" were added and added over time by many different people/groups the features that ended up widely used made into the standards (well I doubt templates and STL or similar were used before the standard, do not understand that one).

Same is true for most language standards. Some of them manage to stay cohesive. NONE of them are created by the standards commities.
Somehow the product of a bunch of really smart guys can come out looking like the product of a mad man. How does that happen? See the history of CORBA or XML or HTML/CSS for a similar examples.
See what I said in this post above.
The question you raise then is: What are reasonable tools?
That is one I would be surprised if any could answer. Every tool has its advantages and dissadvantages.

There is a joke called evolution of a programmer floating around the internet, original author unknown, though many different claims of who it is from. It shows a hello world program, that becomes more and more convoluted and goes from C to C++ to C# in the process with the two most convoluted versions being the "Profesional Programmer", then gets simpler when going to leet, and simpler again to hacker (a one liner that reads C:\>echo Hello World!). Some versions of the joke are slightly modifies, including ones that use the unix # prompt for the echo version.

Look up that joke, it realy does fit, and shows well why I do not like the "Professional Programmer" view of things.
Used to be Coral 66, mandated in the UK for military and government projects.

That got scrapped for Ada. As mandated by the DoD in the USA.

Now it's the turn of C++...

What do you suggest?

Aside: Personally, having worked though the Coral 66 (Military radar) and Ada (Boeing 777) thing. I was amazed and somewhat horrified when I heard they were using C++ for the F-35.
Save power, use fewer cycles total. Assembly Language forever :) .

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: Solution to X-Toolkit and portability.

Wed Nov 23, 2016 7:39 pm

DavidS wrote:well I doubt templates and STL or similar were used before the standard, do not understand that one
There's a lot of things you seemingly fail to understand, David.

Now, I loathe C++ with a vengeance. Mainly by having been in on it when it was wee small, seen its youthful innocence violated, and having spent over a decade as a C++ troubleshooter, coming in to fix or kill C++ projects that had run off the rails. Mostly it was "round the back of the shed, and two barrels upside the back of the head for Ole' Yeller" if truth be told. Exposure to other people's code, especially code written by a horrible mismatch of people adding keywords to their CVs before selling themselves on as technology expert contractors, will cause you to hate.

However, back in the fairly early days, 1990-91 or so, when we first got access to templates (CFront 3.0, IIRC, but they'd been around for a while even then, Stroustroup's original paper dates '88), one of the big problems was collection libraries. There were any number of equally awful and expensive component libraries out there, each with its own awful underlying structure, one of the more common ones involved having to inherit from some "collectable" abstract base class in order to be able to put an object into a collection. Where I was working, we were getting royally fed up with the buggy half-releases of crap we were shelling out for, and managed to get the green flag to start developing our own collection code, for use across the company. It was a big company. It was Mat who had the bright idea of using templates to mould the collection to the objects. Bright guy, Mat, but he originally was a Lisp guy and into metaprogramming, it came as second nature to him. Collection-wise, we ended up looking a lot like what was pushed out a couple of years later in the ANSI draft; close enough that we were able to migrate relatively painlessly to STL. We were not alone, and a lot of code was shared between companies (I believe some of my vector/array code ended up in the SGI implementation of STL). IIRC from hitting it tangentially later on, Booch Components looked a bit STLish, as well, with an emphasis on template metaprogramming.

The early days of C++ were quite "exciting", with a lot of fundamental changes going on, the move from an emphasis on inheritance based, data-type-driven development to the generic and metaprogramming aspects of STL were nothing short of radical.

Easy to miss if you're stuck with insistent on inflicting a sub-CFront pretend C++ compiler running on an ST on yourself, though, I guess.

ejolson
Posts: 2050
Joined: Tue Mar 18, 2014 11:47 am

Re: Solution to X-Toolkit and portability.

Wed Nov 23, 2016 9:34 pm

tufty wrote:
DavidS wrote:well I doubt templates and STL or similar were used before the standard, do not understand that one
Now, I loathe C++ with a vengeance.
So it would appear templates were in use before they were standardized. That clarifies things and seems consistent with the original point.

Heater
Posts: 10021
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Wed Nov 23, 2016 10:01 pm

As far as I understand the C++ standard has followed developments in actual use rather than "invent some crap and dictate it as a standard".

On the face of it, standardizing practice that is tried and tested and works is a good idea.

Heater
Posts: 10021
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Wed Nov 23, 2016 10:20 pm

tufty,

You clearly know a lot more about, and have more experience of C++ than I do. But hearing "inheritance" or "generic and metaprogramming" sends a cold chill down my spine.

To me these things always seem far removed from the problems one is actually trying to solve in a software project.

My experience of leading teams of young C++ enthusiasts is that they leave you with a horrible mess of code that is so tightly interlocked to itself it's impossible to maintain afterwards. Changing anything requires changes everywhere. A nightmare. Not to mention being full of memory leaks!

I tried my best to get them to keep it simple, but it seems inheritance and templates weave their tentacles into everything and dictates what happens. Understanding any line of code can require understanding a whole mess of other stuff. It's almost impossible to see where the work actually gets done!

And those were not even huge projects, just 4 or 5 guys working for a year or two.

User avatar
DavidS
Posts: 3280
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Wed Nov 23, 2016 11:14 pm

tufty wrote:
DavidS wrote:well I doubt templates and STL or similar were used before the standard, do not understand that one
There's a lot of things you seemingly fail to understand, David.

Now, I loathe C++ with a vengeance. Mainly by having been in on it when it was wee small, seen its youthful innocence violated, and having spent over a decade as a C++ troubleshooter, coming in to fix or kill C++ projects that had run off the rails. Mostly it was "round the back of the shed, and two barrels upside the back of the head for Ole' Yeller" if truth be told. Exposure to other people's code, especially code written by a horrible mismatch of people adding keywords to their CVs before selling themselves on as technology expert contractors, will cause you to hate.

However, back in the fairly early days, 1990-91 or so, when we first got access to templates (CFront 3.0, IIRC, but they'd been around for a while even then, Stroustroup's original paper dates '88), one of the big problems was collection libraries. There were any number of equally awful and expensive component libraries out there, each with its own awful underlying structure, one of the more common ones involved having to inherit from some "collectable" abstract base class in order to be able to put an object into a collection. Where I was working, we were getting royally fed up with the buggy half-releases of crap we were shelling out for, and managed to get the green flag to start developing our own collection code, for use across the company. It was a big company. It was Mat who had the bright idea of using templates to mould the collection to the objects. Bright guy, Mat, but he originally was a Lisp guy and into metaprogramming, it came as second nature to him. Collection-wise, we ended up looking a lot like what was pushed out a couple of years later in the ANSI draft; close enough that we were able to migrate relatively painlessly to STL. We were not alone, and a lot of code was shared between companies (I believe some of my vector/array code ended up in the SGI implementation of STL). IIRC from hitting it tangentially later on, Booch Components looked a bit STLish, as well, with an emphasis on template metaprogramming.

The early days of C++ were quite "exciting", with a lot of fundamental changes going on, the move from an emphasis on inheritance based, data-type-driven development to the generic and metaprogramming aspects of STL were nothing short of radical.

Easy to miss if you're stuck with insistent on inflicting a sub-CFront pretend C++ compiler running on an ST on yourself, though, I guess.
Kool story. I can see where you came from.

Though I am not much a fan of meta-programming, never will be.

For me the idea of C++ is OO (structured classes with inheritance). While I have seen very poor collections done that way, it is possible to do very very good and easy to deal with things in C++ without any of the meta-programming/template cow-pie.

I abandoned C++ when people began talking about templates as a way to program. Since then i have written nearly zero C++.

C is a great language, as is Object Pascal, Pascal, QuickBASIC, a subset of FreeBASIC, most Assembly Languages, SmallTalk, and even C++ without templates (so long as used reasonably).

Personally no company could ever pay me enough to work in C++, and the extremely rare project I do in C++ is just that extremely rare.

For me I am much more a fan of procedural languages (and do use a couple functional languages). This is just me.

If I want OO it is easy enough to implement good OO in standard C (K&R-C/C89/C99/C11). A well known example of OO in C that is very simple and complete is BOOPSI (on Amiga OS). Ok operator overloading is one feature of C++ that I miss, though there are a couple of C compilers that implement it as a compiler-specific extension of the language.
Save power, use fewer cycles total. Assembly Language forever :) .

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: Solution to X-Toolkit and portability.

Thu Nov 24, 2016 7:00 am

Heater wrote:My experience of leading teams of young C++ enthusiasts is that they leave you with a horrible mess of code that is so tightly interlocked to itself it's impossible to maintain afterwards. Changing anything requires changes everywhere. A nightmare. Not to mention being full of memory leaks!
110%. The major problem I hit when "called in" was tight coupling. Class X will only work with class Y, and both in the exclusive presence of class Z. It's caused largely by a naive treatment of C++ as though it was just C with classes. The strongly typed nature of the language itself encourages this, and it's this that templates help with (other languages avoid it by treating object boundaries as largely opaque, with the cost of potential run-time issues if you get the wrong object)

Near-vertical inheritance trees, where the code you're looking for is pretty much always somewhere else, make debugging and reasoning about the code difficult, and, again, these things are encouraged, if not actually mandated, by the language itself. Objective-C's (to pick an example at random) emphasis on composition rather than inheritance ("has-a" rather than "is-a" relationships in the object model) results in flatter hierarchies and code that's far easier to reason about, other languages ad object systems go even further (think Javascript's "prototype" model, which harks back to Dylan via NewtonScript; apart from - well everything else about javascript - it's a lovely language).

Memory leaks are avoidable in C++, but it's bloody hard to do, especially given the tight coupling thing. Circular reference loops, multiple ownership, etc - automatic garbage collection was invented for good reason, and the majority of the C++ corpus is a rather pertinent example of that reason.

Now, you say that template metaprogramming seems "far removed from the problems" - in many cases it obviates those problems entirely. In the good old bad old days, if you had a collection of objects, you'd roll your own collection code (let's say, for example, a linked list), and the code for accessing it. Because C++ is strongly typed, you'd have to do this on a per-class basis, or perhaps you'd have everything inherit from some "collectable" abstract base class and do away with any idea of type safety, with casts all over the place. Then, when you find that you've got performance problems with that, or maybe you need to scan the list backwards, you go in and rip out all that scaffolding, in order to make it a b-tree, or maybe a doubly linked list. But then all your iteration code is wrong. And the stuff you wrote to maintain that odd sort order you need suddenly starts breaking because it can't handle millions of objects, or the new underlying collection breaks some invariant or other it requires.

With a stroke of the magical template wand, all of that crap goes away, and you can concentrate on what it it that you're trying to do.

std::list<my_class>

About the only downside is that some declarations start looking like angle bracket soup.

Heater
Posts: 10021
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Thu Nov 24, 2016 10:43 am

tufty,
...the code you're looking for is pretty much always somewhere else,...
Yep. That sums it up nicely.

Javascript is wonderful. Some years ago I did an experiment. I looked at a server process we had that basically juggled a lot of XML from here and there and delivered it else where. I made a Javascript version of the same functionality. I swapped out XML for JSON. I was amazed to find the finished product was only a bit slower that the C++ original. A factor of 2 about. But the code was much smaller, took no time to create, was far easier to understand and much easier to extend later on.

So I continued. What was one of our desktop programs that displayed a graphical data visualization in real-time, written in C++ and using Qt, is now Javascript in a web page, in glorious 3D using webgl. So much easier. And no messing with building and distributing for Windows, Mac and Linux. Even works on tabs and phones.

I get the feeling that the best use of C++ is to create a JS engine, then use Javascript to get your actual application done :)

Mind you, the rot has come to JS. The Java boys infiltrated the standards committee and now JS has a "class" construct...

Heater
Posts: 10021
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Thu Nov 24, 2016 11:12 am

An analogy comes to mind....

Given a big problem one is taught to tackle it by top down design, break the problem into parts that are easier to tackle, break those parts down... Divide and conquer. Decomposition.

So far so good but there are two ways this can go:

1) You end up with a box of lego bricks, of a few different types, that you can then arrange and rearrange into the solution you want.

2) You end up with a box of jigsaw pieces that can only be arranged in one way to get the picture.

Decomposition is great and all. But often it is the reverse, composition, that is forgotten. Of course identifying useful composable parts and actually making them composable is hard.
Last edited by Heater on Thu Nov 24, 2016 4:59 pm, edited 1 time in total.

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: Solution to X-Toolkit and portability.

Thu Nov 24, 2016 4:55 pm

Yeah, Javascript's pretty cool. The main problem with it, as far as I can see, is exactly that it is cool; everything needs to be buzzword compliant and using some utterly unstable hipster framework (usually version 0.1.7.3x pre-beta, or even better, a specific pull from github known only by its UUID). It's all so - fleeting. Ephemeral. Which two words are probably the names of a pair of bloody awful hipster javascript frameworks. Everything needs to reinvent the user interface. Pretend everything is a telephone. Bloody great sites with enormous acreage of empty white space. Where the browser's OS-provided features like "scroll bar" don't work. Where the browser's back button doesn't work. Where searching within a page doesn't work. Sites designed by hipsters. The Civilised Discourse Construction Kit. Kill them. Kill them all. With fire, and, if at all possible, big stabby things. Bury them in a pit filled with <redacted>

</rant>

Sorry about that. I feel better now.

I like javascript for front end stuff, it makes a vast amount of sense if used sensibly. Not so certain for big data processing, though it's my opinion a highly performant language inheriting (if you'll forgive the pun) the prototype/slot concept could go a long way. And that would probably end up looking a lot like server side javascript anyway.

I'm extremely fond of Objective-C, myself. It does "C with classes" right, IMO, shame it's effectively tied to one platform.

Another intriguing language, OO-wise, is Graham Nelson's "Inform". The underlying model is very interesting.

Heater
Posts: 10021
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Thu Nov 24, 2016 5:35 pm

tufty,

Totally with you there.

To be fair, the crazy mess of JS "frameworks" is not Javascript's fault. To my mind the API of the browser, HTML, CSS, the DOM thing, is so clunky, inconsistent and horrible that you pretty much have to build a framework before you can get anything slightly non-trivial done. So everybody does. So there is a new one everyday...

I have watched a ton of presentations from web developer conferences and they are always talking about good design for the web, fluid user experiences, bla, bla. So how come I see all most none of that anywhere on the web? Heck even Google can't make a console for it's cloud services that does not crash out all the time!

My favorite browser framework is vanila.js http://vanilla-js.com :)

After that react.js is kind of small, fast and easy. And most importantly is not a "framework", just a library to focus on solving one problem.

bootstrap is essential because I don't ever want to think about CSS.

I always though Objective-C is the hipster language. Or is so that the hipsters are killing it off with Swift this month. Who knows what happens next month!

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: Solution to X-Toolkit and portability.

Thu Nov 24, 2016 6:27 pm

Heater wrote:I always though Objective-C is the hipster language
Nah, it's been around for ages, and it's a very solid language, despite being tied to what's arguably *the* hipster platform(s). Semi-automatic garbage collection (fully automatic if you want), proper message passing OO as opposed to the "method calling" botch used by C++ and Java, a very big emphasis on composition over inheritance, programming by contract rather than programming by type, late binding, MVC, and very little extra syntax over straight C.

There is a performance hit, but the runtime overhead compared to C++ is easily overweighed up by the terseness of code (far fewer in LoC to do the same thing in ObjC compared to C++) and corresponding reduction in bugs and general arse-chasing, clarity of code, maintainability, and the like.

The language itself isn't tied to Apple, gcc / clang both do Obj-C, and the runtime is GNU. The ties come with what can pretty much be considered the standard library, Foundation and AppKit (and all the other "hipster" stuff), although there are (or were) GNUStep implementations of most of the same APIs. Been a while since I looked at GNUStep, though, and ObjC can pretty much be considered single-platform. Shame, really - way back when there was "Yellow Box" for Windows, which allowed you to write code that ran on both Windows and NeXTStep. And maybe Solaris, I forget.

Return to “Other programming languages”