The Telegram: Starting from scratch

quote:

With technology being prevalent in the world today, it’s become increasingly important to introduce this technology to the youth so they may understand it better and improve upon it.

Progress is being made towards that end at MacDonald Drive Elementary in St. John’s, where Grade 4 students are given the opportunity to learn scratch programming, a form of computer programming.

The Vancouver Sun: Microsoft’s YouthSpark Live teaching coding skills to Vancouver youth


Do you know about Ladies Learning Code? They're learning code not GUI.


The WebFOCUS world will be in a sorry, sticky mess if we're all arm-twisted into using the GUI.

I totally agree.

I don't believe that you can understand the underlying nuances of a language by using the GUI.

It's happening with the spoken language as well. Everyone is walking around with their devices, tapping and pointing and clicking and not speaking.

Will we lose the ability to speak ?

Also grammar has gone out the window as well.

Hm..... Should I spell check this ?

I disagree...

It suffices to learn how a computerprogram works in general.

Any GUI will always contain the concept of general program workflow.
Even if the GUI doesn't literally let the use type IF-THEN-ELSE or GOTO statements. It must support that basic concept. ( something you also see in the WF-GUI ).

I have had a classic education in computer science. Followed up by a Bsc in IT.
Which means I learned how CPU's work on an electronic level. With registers, jumps, operations. Mnemonics like psh, pop, mov, jne, nop, sub, inc, dec, etc.

...are you still with me? If not, it doesn't mean you can not operate a computer.
If you are with me, you have either too much time, or a similar education.

quote:

Waz : I don't believe that you can understand the underlying nuances of a language by using the GUI.

That is true.

The question is: Do you need to?
And the answer to this question will only be answered with "yes" if the GUI doesn't fully supports ALL functionality of the language.

Greets,
Dave

I feel like the old guy yelling "get off my lawn". If the GUI is the only way, then the GUI needs to handle all of the possible coding situations. Unfortunately, this GUI isn't there yet. However, I use MS Word without understanding the underlying code and it hasn't broken on me yet. Sorry just rambling in my old age. :-)

How quaint.

Now, time to debug.

Oh, where do you check, I wonder......

How about the speed aspect? I'm a 2-finger typist, yet I can code a program much faster than pointing and clicking. I'll grant the GUI one thing - it's faster (for me) to do the styling that way, and I'm no expert with html, so the gui is the only way for me when creating launch pages.

But at the basic level, when someone asks me for some data "right now", coding is the only way to go.

IMUO I think that both have their strengths and weaknesses.

GUI have been developed to make life easier and facilitates the things. Better than spending many minutes (or hours) typing code that can be done in a few click with GUI, it's a gain as George's sample with styling.

But GUI are developed using CODE !! If the CODE for a functionality hasn't been added, the GUI cannot perform it where the CODE can.

And because everything is based on CODE, I think that a GUI must support a "CODING" functionality.

Still as MUO, you cannot perform programming without knowing coding.
It's like asking a kid where does the milk comes from and have him answering: "From the fridge".

I also think that knowing the code gives you flexibility and knowledge.

In conclusion: CODE power !! Followed close by the GUI as its shadow :-)

This is such a timely subject and I can't help, but share with you my frustration after my access to the text editor in InfoAssist was revoked last week. The reason: IT doesn't want to support "custom" code. Unfortunately, the replications go way beyond "creating custom code". In may case, in particular, the text editor had been an amazing tool to shorten the development cycle by allowing me to copy and paste existing code, and troubleshoot errors such as the one on the posted picture. Not to mention performance issues. In short, a big loss to my "WF tool box".

Great discussion, and insight everyone! Thanks

Luiz

If I may add my two cents (or maybe sense?), GUI is a great helper for styling and the first layout of a report. Very useful when one wants to do heading alignment and such.
However, once the procedure necessitates lots of Dialog Manager, GUI has no option but retreat lest it becomes a Dog in the Manger...

Nice to see al the different opinions.

Intresting to see people waiting in line to disapprove: "teach gui". Mostly supported by experience with WebFocus GUI and Code.


I don't need to "code" DTP. ( wordperfect died because of this, in favor of Word ( <- GUI ) )
I don't want to "code" CAD or any other 3D software.

Sure, someone has to "code" the GUI.

or not?
...focshell.exe was made not by hand coding C++. But with Microsoft Visual C++ 9.0


Back to the Francis' original hypothesis:

quote:

The WebFOCUS world will be in a sorry, sticky mess if we're all arm-twisted into using the GUI.

True : The WebFOCUS world will be. Doesn't mean the rest of the world does.

Well, I am solidly on the coding-side of this discussion, so I am at least a little biased, but:

quote:

Originally posted by Dave:
I don't need to "code" DTP. ( wordperfect died because of this, in favor of Word ( <- GUI ) )
I don't want to "code" CAD or any other 3D software.

If only Word wouldn't get it wrong so often. With WP you could fix what it got wrong, in Word you'll have to work around what you cannot see.

People are taught CAD (AutoCAD) by typing in coordinates, as that's much more precise and less error-prone than pointing and clicking. On top of that, AutoCAD can be automated using LISP code, which sees a lot of usage on many sites.

So I'd rather be able to code those things, even though I don't need to all the time. Being able to mix and match makes a tool strong, which is why WordPerfect stayed the word processor of choice for so long. Where I think they failed was at adapting to graphical user interfaces (Windows 3); their product just wasn't as stable as the competition and people started losing work because of it - which meant WP started losing customers.

I've been using WebFOCUS since version 4.3, PC FOCUS since the MS DOS days (about 30 years now). Other than occasional styling, I almost NEVER use the GUI. I find it confusing and it generally takes 10 times longer to do anything using the GUI vs. a text editor. One of the advantages of using a 4GL language like FOCUS is that it generally reduces the time to code something by 90% vs. a 3GL language. IMO, using the GUI just gives all that time back.

I have a brand new programmer. He came from the user community and has no formal IT training. I was tasked with guiding his training. We got him started with App Studio and some online IBI classes. I let him decide how he wants to program, GUI or coding. Guess what, even he dislikes the GUI.

I also have a young lady that has been using WebFOCUS for about 18 months now. She came from our PowerBuilder developers. She had been using PB for 8-10 years and was perfectly comfortable with using a GUI. She doesn't like the GUI either.

I don't know anyone that likes or uses the GUI as their primary coding generator.

Even if the GUI could handle every conceivable WebFOCUS syntax, I'll never use it because it takes too long to find it or figure it out.

This message has been edited. Last edited by: jgelona,

GUI can be nice when it saves time. I can imagine that handwriting the BI portal will take a lot more time then it takes now in the GUI.

As long as we can code fexes, masterfiles and htm files I'm fine with GUIfying portal etc. But I think realisticly you can't expect that the GUI will support all coding that you can do. So it's either code or use GUI.

If you purely want to code, why not do it in java or C instead of buying an expensive BI platform?

@Francis

We must of a had a mind sync last Wed, because IBI was up here last Wed and I told David "the top guy over development at IBI" the exact same thing.. He was trying to sell us on App Studio and I realized that it was harder to make code changes and he explained that was their whole direction. I then mentioned to him how people are going to be using "I can't because I'm limited to" if he goes down the road.

I'm an old school developer, **** I don't even like MFC, JQuery, or any of these products that "code for you". Uses 10 times the amount of code to do the same thing I can do making it very inefficient. Technology is already starting to tank with these new developers with their, only do what I'm told, mind set. It's a developers responsibility to speak up when there is an architectural issue, but in most cases these new developers don't know, because their clueless of the over all picture. I get more and more frustrated with the use of software, because it's as if the people selling it, don't use it and know it's not designed correctly. Now IBI is trying to take us all down that road with them.

GavinL, I totally agree with you. I truly believe that if I was the most proficient WebFOCUS GUI expert on the planet, that it would take 5-10 times longer to write the programs and report I do using the GUI and I'd have 3 times as much executable code. Then there is maintenance. You can forget about finding the correct blocks of code to update when the user wants to add a new field or computed fields.

@Luis
how awful. quit that job.

Anyone that has ever developed, I mean trully devveloped knows there is a difference between a report and an application. WebFOCUS allow you to build application that present themself as reports. The GUI will only get you so far period, say 50-75% if you are lucky, sure may even get a little farther if you want to build and maintain duplicate report for every possible scenario.

What about the guided ad-hoc really in the GUI hahaha. So if the GUI does not support it then and you cannot get to the code then users will be the ones who suffer first. If all you have is the GUI then all you'll be able to say to the users when they want some the GUI does not support is NO the tools does not support that, then they hear that enough then they will push for a DIFFERENT TOOL. Then you suffer second when you lose your job.

What I see the true power and benefit with WebFOCUS is that you can get into the code and do what ever you need to do to make it do what the user wants.

Think about a simple HTML Launch page with some input fields and now tell me GUI or CODE?
It all depends on the requirements, there is no one tool fits all in my opinion.

My 2c
-P

I find this an interesting thread. I went back to school, about 2005 to learn computer programing. I learned .net with Microsoft Visual Studio, with autocomplete and all the modern bells and whistles. The second part of my program was learning COBOL and this was on terminal emulator to an IBM i5.
For me I remember the COBOL better than I do the .NET: I actually had to produce the code, not select the correct answer from a provided autocomplete dropdown. It is the difference between having to write an essay on a subject compared to answer multiple-choice questions. The essay shows complete understanding.
I also worked in the school’s computer lab helping students. We had a web development program and students would try to complete very simple webpages, nested tables. Some students would use Dreamweaver. Then what should be a very simple forty lines of code ended up being more than 300 lines. With the vast majority of those lines being superfluous and confusing. Students that actually wrote there webpages in a text editor were much better at making changes and had a more complete understanding of the process.
I think about the programming job interview in which “hand coding” on whiteboard is part of the process. Not being taught to actually write code from memory is a great disservice to people to learn to code. For me the bottom-line is are we computer programmers or report writers? There is a difference.
@Louis : “The reason: IT doesn't want to support "custom" code.” I think this stems from IBI’s implementation of JavaScript in WF8. I seam to remember any ‘custom’ JavaScript – anything you typed on a keyboard – may not make the transition from WF7.7 to WF8.

writing code, like doing homework, engages the left hemisphere of the brain, which is where memory happens.
gui clicking fails to begin the memory process.

I'm firmly in the "Let me at the Code" camp, but just to be fair, I also firmly believe that a strong GUI has its place beside the code. DJones brings up working next to people with Dreamweaver. Dreamweaver is actually a great example of melding GUI with Code, I can have the text editor and visual display of the web page open at the same time and seamlessly move between the two. Maybe there is a concept I'm not too firmly with, but understand how to manipulate. I can pull the object out of the ribbon, and then move to the text and make my edits. Its very seamless and Dreamweaver respects the code I've entered, even if it hasn't be updated to recognize newer syntax in HTML.

When I'm stuck on a particular piece of syntax, I will often make the change in the GUI and then look at the code to see how it worked. I've found this very helpful in many situations. I think starting in the GUI is good for beginners and people who will never want to be programmers / developers. These types of people I am glad to have using Info Assist or a Guided Adhoc solution. As a person grows in their understanding of BI and WebFOCUS, the GUI can be a good way to teach them how the code works. ie You did this in IA, now see what it did under the covers. It's a lot easier for people to visualize what it is they are doing that way.

I personally believe that GUI is at its most powerful when it can automate the completion of multiple tasks with minimal clicks. What I mean by this moves into why, with all the issues I have with HTML Composer, I still start all my launch pages with it. The composer simplifies the XML necessary to run reports from the procedures and writes a ton of code, with very little effort. But once that task is done, I switch to HTML and code by hand because it is much easier and faster (and more accruate) to do so.

I understand, as I've been told multiple times by IBI, that the GUI will never be able to fully capture all of the capabilities that you have when coding by hand. Loops, Comments, and Go To's within the Table declaration (for instance) will never be supported by the GUI. HTML Composer will probably never be able to handle Nested DIV tags (or even DIV tags at all) And thats OK. But when you take my ability away from doing things like that, you take away a lot of the power and customizability that brought me to enjoy working in WebFOCUS in the first place.