[jon.kiparsky]

BenignDesign, on 04 December 2012 - 10:04 AM, said:

Seriously, I always thought it was oriented, not orientated.

You were right.

Spoiler

I have quit stabbing people when they say "orientated", because it didn't help (much) but you were right.

[modi123_1]

I was just informed by the tubez it is a US vs Brit break down on the word and somehow I have gone all my life using the brit version.

I feel quite.. unclean.

It might just be some sort of long held over family/regional thing.

[jon.kiparsky]

Just checked with Pierce in our London office. He says both he and his other use the two-t version. News to me. I guess I can no longer assume that people who say "orientated" are illiterate. They might be limeys.

[modi123_1]

I understand jon... it's akin to when those union-jack thugs type things like "colour", "maths", or "mum".

(ir)Regardless I just did a quick ransack on my work's document store and it seems I use both.

Odd.
Real odd.

I am not sure if I even know who I am anymore.

[lordofduct]

Both words are real, both words come from the same French verb (orienter), oriented was popularized first.

You can swap them out as you please, generally you go with which sounds better in the sentence you're saying/writing.

I prefer oriented, and orientation.

I wouldn't say it's similar to color and colour. That's more of a regional thing, where as oriented and orientated is a time thing. The shorter preferred in the 18th century, and the longer in the mid 19th century.

This post has been edited by lordofduct: 04 December 2012 - 08:28 AM

[BobRodes]

I used to teach a UML class, and the idea of automatically generating code entirely from UML diagrams was quite the rage. I don't see it, personally. It reminds me of a very early Mac database program that was so enamored of the mouse that it required you to write code by dragging commands from a menu into a code window! No typing allowed. It was an incredibly tedious way to do things.

In the end, using diagrams to generate code doesn't strike me as a simplification. The fact that no such idea has taken hold although they have been around for 20 years suggests not so much that they are unworkable as that they don't reduce development overhead enough to go to the expense of developing them.

You actually can create class diagrams in VS and generate class definitions from them, which might reduce some busywork. But consuming those class definitions still is easiest done by hand.

This post has been edited by BobRodes: 04 December 2012 - 10:50 PM

[jon.kiparsky]

BobRodes, on 05 December 2012 - 12:48 AM, said:

In the end, using diagrams to generate code doesn't strike me as a simplification. The fact that no such idea has taken hold although they have been around for 20 years suggests not so much that they are unworkable as that they don't reduce development overhead enough to go to the expense of developing them.

As I've said before, if you're working on things that can be simplified by diagrammatic construction, or drag-and-drop coding, it's likely that your design isn't very good or that you've failed to capture some essential similarities in what you're building which would make it even easier still to build it with text.

This sort of stuff depends on stereotyped patterns, leveraging those into mouse gestures. Good design captures stereotyped patterns and abstracts them out to eliminate them, so what's left is more signal and less redundancy. What this means is, if you do good design, the opportunities to leverage steretyped patterns are eliminated.

[erad]

TIBCO is basically this (programming by diagram). I used this for a good two years in my previous job developing middleware. Its just another layer of abstraction that allows an even less technical mind to understand a system, however, every time you add a layer of abstraction, you remove a layer of flexibility. If TIBCO hadn't created an 'activity' (a picture that you drag on to your diagram that performs a particular function) that you needed, you were stuck.

This is a layer of abstraction too far to ever become an every day programming language/tool. It has its uses if non-technical people want to perform simple tasks, but don't worry, proper programming with words, colons and the use of a brain will always be required. After all, TIBCO needs Java developers to write the tool that you draw your diagram in.

Lego Mindstorms is very similar; its designed to introduce programming to kids by allowing them to build and program a robot. Its a brilliant tool for introducing children to the fun of coding without having them stare at 100 lines of words and curly braces. Diagrammatic programming definitely has its niche uses, buts its never going to replace programming languages.

[cfoley]

Some code is ideally suited to being automatically generated, defined via a wizard or being directed by drag and drop. Build scripts and GUI layouts often (but not always) fall into this category and I'm sure that plenty of stuff in the world of testing also does (mock objects, for example). This is great because I can spend my time writing other, more interesting code. However, most problems need at least some level of human input to design a viable solution.

As others have said, handwritten code is the best tool for most of these solutions. A great example is Windows. You could have been forgiven for thinking that Windows would be the end of the command line but I think every programmer has at least a small handful of tasks for which he would always turn to the command line.

[khedron]

well even if programing as you know it does end , it will just give way for a new kind, if you can program easier , it only makes sense that you will be able to make more advanced and capable programs at a faster rate , making one programmer much more capable than before.

[jon.kiparsky]

Interesting thought. So let's imagine that in the universe of programmers, these tools would simply bump every programmer up by one level. So A gerat programmer becomes a god, a good programmer becomes great, and so forth... down to a completely incompetent programmer becomes merely inept.

The trouble is, there are a lot more completely incompetent programmers now, who aren't programming anything at all, than there are, say, good programmers. So this implies that we'd see a huge rise in inept programmers - good enough to be in the market, but just barely - and a much smaller rise in great programmers.

You see how this could backfire?

[cfoley]

It's OK. There wouldn't be any more jobs than there are just now.

I tend to agree with khedron. As programming tools get better so does the software we can make.

[ishkabible]

I strongly believe that kinds of embeddable scripting and Turing complete(or at least extremely flexible) configuration means would be a very good design in most software becuase it allows the software to be reused by the consumer. I think as the means by which things are configured become better and better you will see less and less crappy programmers becuase it will be in a good secretary's skill set to do what a crappy programer can currently do. Hence crappy programers wont be hired becuase no one will be requesting the kinds of applications they could make becuase they can do it themselves.

that said the number of programmers would shrink the way I see it

This post has been edited by ishkabible: 05 December 2012 - 07:48 PM

[BetaWar]

The end of programming is like the end of the world. People keep saying that it is coming, but it never does.

[BenignDesign]

12-21-12.
/thread.