|
BillWoodruff wrote: I am almost certain, given the code style, the author learned C# programming here on CP by using QA !
But he/she had mistaken the answers with questions.
|
|
|
|
|
That's really terrible code! oooh! my eyes! they hurt soo much...
|
|
|
|
|
Google/gmail recently sent me a message on my gtalk saying that it is no longer supported and that I should try hangouts. Now, I've been trying hangouts and although it seems trendy and all, I just can't seem to wean myself off gtalk.
Infact I noticed that gtalk is still in beta, which means I've been using it all this while in beta, and it's going out of support without having officially been "released"? This is funny and sad, if it works why fix it? Does this remind you of the murder of Windows XP by MS?
|
|
|
|
|
Wrong forum.
"a place to post Coding Horrors, Worst Practices ... code that simply boggles the mind. Lazy kludges, embarrasing mistakes, horrid workarounds and developers just not quite getting it"
|
|
|
|
|
Maybe it's weird that anyone used it?
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
|
|
|
|
|
I never used GTalk much, and don't use Hangouts much, so I've hardly noticed a difference when I do. Skype hasn't changed in yonks, and that's my main 'chat' line.
|
|
|
|
|
eyesark wrote: if it works why fix it? Because you cannot sell DOS anymore, even though it is not "broken".
eyesark wrote: Does this remind you of the murder of Windows XP by MS? No, XP was out of beta.
..but do I read it correctly that you are still supporting all of your software that has not "broken"?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hangouts is the release version of Google Talk - renamed and 2.0.
That's all.
|
|
|
|
|
The next big thing will be drag n drop language. You build the language using old flowchart symbols that you build your skeliton with then just add the properties. Nice and simple ...
|
|
|
|
|
You should check out the macro editor for Project Spark (Xbox game) - it is exactly what you describe.
|
|
|
|
|
Mac DB from the 80s - Double Helix II.
Been there, done that. I was one of the authors.
According to my calculations, I should be able to retire about 5 years after I die.
|
|
|
|
|
Probably not the best forum.
You remind me of a concept whose name I can never remember -- something like "rational programming" -- that ultimately falls down because it fails to take human nature into account. The main shortcoming is that some developers (me, for example) don't always use good meaningful names for things.
The second shortcoming was that, although applications could be written with high-level constructs, someone still had to write those constructs in a lower-level language -- and provide meaningful names and reasonable interfaces.
In fact, a few years back I spent a year having to develop applications in a rule-based environment that was like that.
Edit: And SSIS is kinda like that too.
|
|
|
|
|
So whose going to write the code behind those little symbols and in what language?
No, it's not going to be the next big thing. It'll be a niche market.
Seriously, can you imaging "writing" a large business application using a language like that?
|
|
|
|
|
Dave Kreskowiak wrote: a large business application using a language like that?
Oh, I don't know... MULTIPLY Quantity BY UnitPrice YIELDING LineItemCost seems familiar.
|
|
|
|
|
I was referring to more of the graphic image of drag and drop code taking up a ton of space on screen instead of the more compact text version.
|
|
|
|
|
That seems to be the universal reason why text still is dominant. It is difficult (at best) to build an environment that at least encourages breaking algorithms into small pieces so as to be easy to manipulate. Also, it is desirable to be able to arrange graphics to avoid crossing lines - which is a fiendish problem in the general case.
According to my calculations, I should be able to retire about 5 years after I die.
|
|
|
|
|
Dave Kreskowiak wrote: Seriously, can you imaging "writing" a large business application using a language like that?
I actually think that would be fantastic. Obviously, it has "real code" in the background, but why not build a business app (of any scale) with a visual way of wiring together modular components, custom behaviors, etc.? But even that, in my thinking is "old school" - which is why I'm so fascinated by what the potential applications are for the open source project I'm working on in my spare time (see sig.)
Marc
|
|
|
|
|
Remember the "3rd Generation Languages" from the 90s?
SqlWindows,PowerBuilder, etc?
They took a reasonable stab at doing exactly this. But they always ran up against exactly what you're talking about.
It turns out that the hard part is the hard part and that's actually what we do.
|
|
|
|
|
Salesforce (which I have the dubious honor of having worked in the past week) is rather close to this. It's not so much drag-and-drop as it is click-and-click, but the point still stands. And they have an absolutely massive user base.
|
|
|
|
|
Salesforce is popular because of its data tracking abilities, not its programming language.
|
|
|
|
|
Nope.
They try this every few years and it never works out.
The problem is that all of the stuff that can be "drag and dropped" equate to simple libraries.
Programming is all about the customization work.
|
|
|
|
|
Sounds like JSD to me (followed by a JSD to COBOL translator).
That's the second time this week I've referred to COBOL - I think I'll go lay down.
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
|
|
|
|
|
You describe WF (Workflow Foundation), don't you?
Just another "programming language" for people who do not know programming - like Cobol, Mumps etc.
And guess who will have to write all the programs in that language?
|
|
|
|
|
It's called Simulink but there are tons of others. It is a widely used paradigm in embedded designs that must be precisely documented AND thoroughly tested, as in ISO26262 for automotive applications for example.
It has some advantages:
+ The "code" is always documented because it doesn't exist - there is only the model and the model is self-explaining (almost).
+ The model is platform independent, it depends only on a formal description of the environment on which it will run and a set of standards as AutoSAR to be deployed.
+ It is usable by designers specialized in other fields, experts of the domain, keeping an underlying code widely tested and homogeneous, requiring little developer/sysadmin assistance.
The drawbacks of course are that someone still codes the model->code translator, set the standards, revise the standards, correct bigs which now can span on zillions of platforms. Also, if you look at the code produced you can see horrible things, as Discrete Integrations used in place of a simple counter and check and so on - if you need performances you are done for.
|
|
|
|
|
IBM tried this - it was called VisualAge[^]. It used a pictorial representation of programming elements. Lines connecting the elements represented relationships, like assignments and events. It all sounded so very cool.
Until you discovered that VisualAge gave you no way to document what you were doing: no comments.
Until you discovered that any significant task resulted in dozens of boxes connected by hundreds of lines in an incomprehensible mess.
Until you discovered that VisualAge applications were glacially slow to start up and to run.
Until you discovered that VisualAge stored your project in a data base, and it routinely corrupted that data base destroying your entire project. We got into the habit of copying the data base before any significant change. In some cases, the corruption was silent, and would not crash the project until later. You would have to backtrack to find the last truly "working" version.
At one time, the VisualAge team was #1 on my list of development-teams-put-against-the-wall-when-the-revolution-comes.
Software Zen: delete this;
|
|
|
|