|
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;
|
|
|
|
|
Scratch and about a billion other teach-kids-to-program appreciation use this paradigm - and it is becoming more popular to learn.
And things like it have been around for a long time.
Perhaps someone will eventually 'get it right' - I notice that there's a new Minecraft modding system allowing you to mod minecraft in Javascript, using either drag and drop or hand-writing code; If it allows one to customise code, it may be the beginnings of something - but I think we might be a few years away.
Then we'll all just continue what we're doing now, except there will be a lot more images posted in Q&A 
PooperPig - Coming Soon
|
|
|
|
|
|
Hang on. Didn't Microsoft say they 'loved' Linux?
And, surprise surprise, they've given it the seat by the kitchen doors again.
Still. The Microsoft restaurant serves junk food anyway. 
|
|
|
|
|
|
I dunno. There's another?
|
|
|
|
|
When I first learned BASIC in the '80s, the only structure available was the array, so we had to use that and build up more complex structures, but that's just not necessary with C#, OOP, and Collections. So I am saddened to these posts from the last few days:
"Int32[] playerNumbers, String[] playerLastName, Int32[] playerPoints" --
Arrays how to delete multiple entries[^]
"Int32[] playerNumbers, ref Int32 playerCount, String[] playerLastName, Int32[] playerPoints" --
Cannot convert type int[] to int[^]
"Int32[] playerNumbers, ref Int32 playerCount, String[] playerLastName, Int32[] playerPoints" --
delete method not deleting[^]
"Array carPark[10][2];" --
What Is Wrong With The Code And Why Doesnt It Run When I Try To Run It In C#[^]
Those first two are the same member, the third probably is as well.
The fourth is at least using a two-dimensional array, but he obviously copied it from somewhere and has no idea what it is.
Oh, sweet Bob, they keep coming...
"public string[][] Select(string query)" --
How to return array or list 2 dimensional from SQL Query[^]
WTF!?
"ProcessDelete(Int32[] playerNumbers, ref Int32 playerCount, String[] playerLastName, Int32[] playerPoints )"
method for copying array into new array[^]
And they just keep coming:
"ProcessDelete(Int32[] playerNumbers, ref Int32 playerCount, String[] playerLastName, Int32[] playerPoints)"
Trouble With Arrays And For Loops[^]
"DeletePlayer(Int32[] playerNumbers, String[] playerLastName, Int32[] playerPoints, ref Int32 playerCount, Int32 MAXPLAYERS)"
For loops and decrement with arrays[^]
|
|
|
|
|
Looking at that last one there are several things wrong with it.
If this is a school project then perhaps it is the teacher that needs pulled out of the 80's
|
|
|
|
|
ledtech3 wrote: If this is a school project
That's very likely.
ledtech3 wrote: teacher that needs pulled out of the 80's
Indeed. I know I'm old-school, but this is a ridiculous level of archeology.
|
|
|
|
|
PIEBALDconsult wrote: I know I'm old-school
ftfy
|
|
|
|
|
PIEBALDconsult wrote: When I first learned BASIC in the '80s, the only structure available was the array,
Then C introduced the struct.
Then C++ decided struct should have methods, and called it a class and added all sorts of other artifacts (inheritance, polymorphism, and encapsulation.)
Then came along relational databases, and we were introduced in C# to a newfangled way of working with structures, the DataTable, DataView and DataSet, but those caused impedence mismatches so a new artifact was born, the ORM.
Then the jar-heads decided to inflict themselves on the process because this was all too complicated and created JSON, a string "structure" that took us back to the BASIC 80's of untyped data and structure encoded in the string itself. Simultaneously, the "kids" (who were not even a glimmer in the eyes of their parents in the 80's) decided that relational databases were bad and gave us NoSQL, which, guess what, uses JSON, is document oriented and requires client-side callbacks to "join" data across documents.
And this is called progress.
Marc
|
|
|
|
|
Marc Clifton wrote: Then C introduced the struct.
Exactly, even Pascal has records (?), variant records as well.
Of course in Perl you'd have to use a hash (  ), but at least it's something.
|
|
|
|
|
To say nothing of COBOL.
No please, say nothing of COBOL!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
|
|
|
|
|
I didn't. I didn't even think it. Until now, thank you very little.
|
|
|
|
|
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
|
|
|
|
|
I'd heard of COBOL.NET, but since I last touched COBOL almost 30 years ago I though I'd do a quick search. I found this:
program-id. Program1 as "ConsoleHelloWorld.Program1".
data division.
working-storage section.
procedure division.
display "Hello World"
goback.
end program Program1.
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
|
|
|
|
|
You can use COBOL to write restful webservices these days...
http://azac.pl/cobol-on-wheelchair/[^]
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
