Re: Why must have two version of PB in future?
![Paul Horan[Sybase]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Paul Horan[Sybase]
personally...
--
Paul Horan[Sybase]
http://paulhoran.ulitzer.com
<Chris Pollach> wrote in message news:4c362715.168...@sybase.com...
> Hi Terry;
>
> Yes, like taxes - you know you are going to get s****d at
> some point. Its just how bad and when. :-)
>
> However, you can soften the blow of deprcating a feature
> if you provide a ton of new features - or at least distract
> the developer with lots of shiny "bling". :-)
>
> In the end though, I still think that Sybase needs to
> solicit actual PB developer feedback before they embark on a
> release and its feature changes must be well known. That way
> the PB community can verify whether a certain direction,
> deprecation or lack of a feature (because Sybase thought
> something else was more important) is really what is needed
> to sell IT management on springing for the next release.
>
> Maybe I am just too logical and used to the old software
> vendor ways. :-)
>
> Regards ... Chris
>
>
>
>> You get burned by a 3rd party control vendor or you get
>> burned by Sybase dropping support for a feature. The end
>> result is the same: you are burnt toast. So your
>> argument for not wanting to use a 3rd party control
>> because that's so dangerous is simply invalid.
>>
>> --
>> Terry Dykstra (TeamSybase)
>> http://powerbuilder.codeXchange.sybase.com/
>> http://casexpress.sybase.com
>> product enhancement requests:
>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>
>> <Chris Pollach> wrote in message
>> > news:4c35ebe0.74f...@sybase.com... Hi Jason;
>> >
>> > WOW .. no OLE or PL experience in all those years - my
>> > you lead a sheltered PB life! I have implemented so many
>> > PL and OLE applciations I have lost count. :-)
>> >
>> >
>> > Yes, if you want to just follow the MS way of life
>> > then 3rd party controls are a necessity. IMHO they
>> > should only be used as a last resort and the DEV tool
>> > should provide a comprehensive suite (WinDEV does for
>> > example). Take a look at VB though and over the years
>> > how many developers got burned as control vendors
>> > evaporated or MS technology changed and the control
>> > vendor could not keep up. That caused excrutiating pain
>> > for many VB developers. Personally, as a PB developer I
>> > want to be insulated from those type of things and why I
>> > would buy PB over VS. Otherwise, we might as well all
>> > just switch over to VS (ooops - did I say that - <my
>> bad>). >
>> > Regards ... Chris
>> >
>> >
>> >
>> >
>> >
>> >> 1: Sybase has already said that Pipelines are in the
>> >> works. I know people use them. FWIW, I never have...
>> >> that's 13 years of experience talking, too. OLE? I've
>> >> never used that, either. What's MS forecast on OLE?
>> MDI? >> As stated, MS took this out and the rest of the
>> industry >> has found better ways. Performance? Yes. I'll
>> give you >> the performance point.
>> >>
>> >> 2: http://www.componentone.com/SuperProducts/StudioWPF/
>> >> www.devcomponents.com
>> >> http://www.telerik.com/products/wpf.aspx
>> >>
>> >
>>
> http://www.infragistics.com/dotnet/netadvantage/wpf.aspx#Overview
>> >>
>> >> Many, MANY people say that one indicator of a product's
>> >> viability is the presence of a 3rd-party market. You
>> >> should WANT PB to expand its 3rd-party market and you
>> >> should be EXCITED that PB can now tap in to the WPF
>> >> 3rd-party market.
>> >>
>> >> And having the bells and whistles straight out of the
>> box? >> If ANY product did that (including VS and WinDev)
>> , the >> businesses above wouldn't be in business.
>> >>
>> >>
>> >>
>> >> On 7/7/2010 8:39 PM, Chris Pollach wrote:
>> >> > Hi Evan;
>> >> >
>> >> > S1: WPF makes it much easier to provide such
>> innovative >> > interfaces A1: I was only parroting what I
>> was told by >> > Sybase. So far the WPF limitations,
>> performance, lack of >> > classic features like PipeLines,
>> OLE, MDI, Profiler, etc >> > make PB 12.net interesting to
>> look at but, I personally >> > would not even attempt a
>> production application with it >> at this point-in-time. >
>> >> > S2: 3rd party controls
>> >> > A2: S****w 3rd party controls <bg>! I have burned so
>> >> > many times by these I have lost count. That is why I
>> >> > have used CVUO and DW's to emulate allot of GUI
>> interest >> > since PB 4. Surprisingly, the PB 4 PB
>> objects I built >> then still work in PB 12 Classic (and
>> somewhat WPF). >> > Frankly, if I am paying good $$$ for
>> an enterprise >> > development system I expect all the
>> "Bling" out of the >> box and have the vendor committed to
>> supporting it. > >> > S3: I can tell you that isn't going
>> to happen >> > A3: TTFN PB - hello new RAD IDE (sad but
>> true, as now >> > dictated by many IT managers).
>> >> >
>> >> > S4: still have the rest of your list to tackle ;-)
>> >> > A4: Will that be ready to test by Monday? :-))))
>> >> >
>> >> > Regards ... Chris
>> >> > President: OSUG / STD Inc.
>> >> > Blog: http://chrispollach.pbdjmagazine.com
>> >> > SourceForge:
>> http://sourceforge.net/projects/stdfndclass >> >
>> >> >
>> >> >
>> >> > <Evan [Sybase]> wrote in message
>> >> news:4c34ab42$1@forums-1-dub... >> Chris, most of the
>> >> items on your list are easier for us to get to in >>
>> the >> new IDE and by leveraging the .NET platform - both
>> at >> design-time >> and runtime.
>> >> >> I've seen you mention (1) before... WPF makes it
>> much >> easier to >> provide such innovative interfaces so
>> I'm >> surprised at your comments >> in other threads
>> saying you >> (or other organizations) see no need to >>
>> move to WPF. >> >> There are already many 3rd party
>> controls that provide >> what you're >> asking for...
>> perhaps what you are really >> saying is you want all
>> these >> things built-in (ie, >> free)? >> If so, I can
>> tell you that isn't going to >> happen. Maybe there will
>> be >> some additional controls >> here and there, but we
>> still have the rest of >> your list >> to tackle ;-) >>
>> >> >> Evan
>> >> >>
>> >> >>
>> >> >> <Chris Pollach> wrote in message
>> >> >> news:4c349dd3.404...@sybase.com...
>> >> >>>
>> >> >>> Hi Reed;
>> >> >>>
>> >> >>> Thank you so much for the insider views!
>> >> >>>
>> >> >>> FWIW: Whatever Sybase decides, it needs to be able
>> to >> >>> empower PB developers to address the major
>> negatives >> that >>> end users criticize PB applications
>> for: >> >>>
>> >> >>> 1) Why can't PB applications look more like
>> MS-Office? >> >>> => I would challenge Sybase here to also
>> go beyond >> that >>> and strive for innovative interfaces
>> - for >> example: >>>
>> >>
>> >
>>
> http://www.mozilla.com/en-US/firefox/beta/features/#feature-firefox-bottom
>> >> >>>
>> >> >>> Developers need to be able to have more control
>> over >> menu >>> options (like SLE and DDLB's on the menu
>> bar, >> control over >>> applications IDE by user
>> preferences >> (skins), carousel; >>> split bar; pane; etc
>> built-in >> controls, etc). >>>
>> >> >>> 2) PB applications need to be FULLY web enabled.
>> >> >>> => That is to say, they need to be able to run
>> using >> >>> CLF/508 standards in current browsers like FF
>> , Chrome, >> >>> Opera, Safari, and IE (at a minimum).
>> >> >>>
>> >> >>> 3) Web services need to be improved to handle newer
>> >> >>> standards like WSE 3.0.
>> >> >>>
>> >> >>> 4) Bult-in integration with popular software like
>> >> >>> SharePoint, SalesForce, SAP, etc
>> >> >>>
>> >> >>> 5) Support for latest MS-O/S releases and features.
>> >> >>>
>> >> >>> 6) Integrated Testing Tool
>> >> >>>
>> >> >>> 7) Integrated SCM
>> >> >>>
>> >> >>> 8) WM7, Android and iPhone support (for PK)
>> >> >>> etc
>> >> >>>
>> >> >>> NOW ... as a PB developer I personally do not care
>> if >> the >>> NET vs the Classic IDE empowers me to
>> deliver >> these things >>> to the business user. What I
>> need to >> reply on is that Sybase >>> can deliver these
>> types of >> things (which I call the Critical >>> Success
>> Fators) that >> developers and business users need >>>
>> today [actually >> yesterday]. Sybase also needs to
>> provide a >>> SOLID >> migration path for the current
>> mission critical Win32 >>> >> applications. So if PB.NET
>> is the future then it needs to >> >>> support Win32
>> targets before IT would even consider >> moving >>> into
>> that environment (IMHO). >> >>>
>> >> >>>
>> >> >>> Regards ... Chris
>> >> >>>
>> >> >>>
>> >> >>>> *** OPINION ONLY ***
>> >> >>>> *** NOT OFFICIAL IN ANY MANNER ***
>> >> >>>> *** Background Only ***
>> >> >>>>
>> >> >>>> First - yes - PB.NET is a "disruptive change"
>> >> >>>> We acknowledge that...
>> >> >>>> And we had many discussions when we started
>> >> >>>> down that path for PB.NET.
>> >> >>>>
>> >> >>>> However, like everything in life, we needed to
>> >> balance >>>> the cost/benefit of the path to reach our
>> >> ultimate goal. >>>> The goals for PowerBuilder include
>> >> (unordered list): >>>> - "native" integration with .NET
>> >> framework. >>>> So your NVO's and eventually Visual
>> UO's >> can be >>>> used by ANY .NET language
>> >> >>>> - conversely, using ANY .net class or control
>> >> >>>> - ultimately the web based solution - from the
>> >> >>>> beginning we viewed WPF as a stepping stone
>> >> >>>> on the path to Silverlight (even when
>> >> >>>> Silverlight had a different name).
>> >> >>>> All this for both the DW and regular Windows.
>> >> >>>> - improvements to all the layout painters
>> >> >>>> - improvements to all the script painters
>> >> >>>>
>> >> >>>> To accomplish this we had three basic choices:
>> >> >>>> a) continue to add to the almost 20 year old
>> >> >>>> PowerBuilder IDE framework
>> >> >>>> b) base a new IDE on Eclipse
>> >> >>>> c) Partner with Microsoft and base a
>> >> >>>> new IDE on Visual Studio
>> >> >>>>
>> >> >>>> Needless to say, many people wanted to continue
>> >> >>>> adding features to the
>> >> >>>> existing PB "classic" IDE framework.
>> >> >>>>
>> >> >>>> However, the small group of us in Concord figured
>> >> >>>> it was futile so we broke off and chose between
>> >> >>>> Eclipse and VisualStudio (now offering the SDK).
>> >> >>>> (Remember the PB IDE internals are almost 20 years
>> >> old. >>>> Ever work on a 20 year old application that
>> has >> lived >>>> through a dozen MAJOR releases - OY).
>> >> >>>> Between Eclipse and VS - not an easy choice -
>> >> >>>> we have experience with Eclipse internals and
>> having >> >>>> all the sources does come in handy...
>> >> >>>> However, based on the .NET/WPF/Silverlight
>> >> requirements, >>>> we figured that using VisualStudio
>> as a >> starting point was >>>> more in-tune with what YOU
>> (the >> customer) would need. >>>>
>> >> >>>> The result gives you (the customer) a choice
>> >> depending on >>>> your requirements.
>> >> >>>> a) PB-Classic to stay in the Win32 world a bit
>> >> longer. >>>> Not forgotten and still being enhanced.
>> But >> the >>>> Concord IDE folks are not focusing on it.
>> >> >>>> b) PB.NET for apps with eye-candy (not filling but
>> >> >>>> sugary goodness), with juicy layout and script
>> >> painter >>>> enhancements, simpler SCC, add-ins, and a
>> >> better >>>> chance of using .NET controls and classes.
>> >> >>>>
>> >> >>>> Anyways....
>> >> >>>> The IDE team attacked the desires and requirements
>> >> above. >>>> We could either take an extra 10 years and
>> >> wedge it into >>>> the "well-aged" classic IDE, or be a
>> >> bit more timely >>>> and INCREMENTALLY back-fill while
>> >> still >>>> providing new capabilities.
>> >> >>>>
>> >> >>>> HTH (maybe just a little),
>> >> >>>> Reed Shilts
>> >> >>>> Concord, Mass
>> >> >>>> <Standard-Disclaimers-Apply/>
>> >> >>>>
>> >> >>>> *** OPINION ONLY ***
>> >> >>>> *** NOT OFFICIAL IN ANY MANNER ***
>> >> >>>>
>> >> >>>> On 6 Jul 2010 21:42:54 -0700, Harimada wrote:
>> >> >>>>
>> >> >>>> >Hi All,
>> >> >>>> >
>> >> >>>> >Please tell me why in the future PB still have
>> >> Classic >>>> and >NET version. For me, I a bit confused
>> >> with which >>>> version >should must i choose. Why does
>> >> not Sybase produce >>>> only one >PB version that could
>> >> offer everything in >>>> development. >
>> >> >>>> >One other thing after PB classic application
>> >> migrated to >>>> >PB.NET, there is no other way to
>> 'turn >> back' to classic >>>> >application.
>> >> >>>> >Please Advise.
>> >> >>>> >
>> >> >>>> >Regards.
>> >> >>>> >Harimada Sabalkunan
>> >> >>>>
>> >> >>
>> >> >>
>>
>>
Bruce Armstrong
It seems to me that some customers were fully behind the product
direction not too long ago. There were statements such as:
"However, if you look at this from the business application developers
perspective - not the utility or game developers POV - I think that PB
12 with its WPF based DataWindow may be the better platform for these
type of applications. Just my "warped" $0.02 on the subject. :-) "
"No, we just need PB to open up access to the .Net controls. That is,
once we can inherit from the .Net classes - we should be off to the
races! :-) "
People asked that they be allowed to work with .Net visual classes,
including 3rd party controls, not just .Net non-visual classes, and
Sybase delivered.
People asked that there would be support for generating fully managed
code, and Sybase delivered.
This stuff wasn't done in a vacuum. Poeple may have changed their
minds about what they want since, but that doesn't mean that the
product features weren't driven by the demand from the customers at
the time.
When Sybase originally started working on PB12, I don't anybody would
have imagined that Apple would release a tablet device that would
become widely popular, and then Apple would dictate that the only way
RIA content would be supported would be HTML5. I don't think anybody
at the time would imagine that Microsoft would abandon the current
basis for it's mobile OS and craft a new one based on XAML.
They face the same dilema with Silverlight/HTML5. If they decide
today to focus all their efforts on Silverlight, they may find out
when they deliver a year and a half or more from now that Apple
actually succeeded in killing it off with HTML5. Or, if the focus all
their efforts on HTML5, they may deliver a year and a half or more out
only to find that there some of the current limitations of HTML5 still
haven't been resolved and it hasn't been widely accepted, but that
Silverlight has become widely accepted. Either way, if they guess
wrong, some customers will come back and blame Sybase for not
listening.
-----------------------------------
My Web 2.0 Stuff
Blog: http://brucearmstrong.sys-con.com/
Facebook: http://www.facebook.com/people/Bruce-Armstrong/1600223798
LinkedIn: http://www.linkedin.com/in/bruceaarmstrong
Twitter: http://twitter.com/bruce_armstrong
Ning: http://powerbuilder.ning.com/profile/BruceArmstrong
Xing: http://www.xing.com/profile/Bruce_Armstrong
YouTube: http://www.youtube.com/user/brucearmstrong
Fotki: http://public.fotki.com/brucearmstrong/
Mark
"Terry Voth [TeamSybase]" <seq...@techno-kitten.com> wrote in message
news:vt3e36tv2ct0thb0o...@4ax.com...
>I can't give you a definitive answer, but how about so we can do UIs
> like this:
>
> http://www.soluto.com
>
> (BTW, IMHO this is a pretty good start up manager for beta. Once the
> Wiki gets populated more, it will be killer.)
>
> Looking at the program directory, it uses http://www.amcharts.com,
> which only come in Flex, Flash, WPF and Silverlight. To me, this looks
> like a practical use of the "swishiness" that WPF has to offer.
>
> No, you don't "need" this for business apps. (Soluto could have put
> this data in a grid DataWindow.) Mind you, using the same mind set, 25
> years ago I was arguing that mice had no place in business apps and
> GUIs were great for graphics designers and that's it. <g> Time moves
> on; people's expectations change. PB12 tried to get ahead of the game
> for a change (at least ahead of the majority of user expectations),
> instead of playing catch up. Did it jump ahead on the wrong path?
> We'll know for sure in 25 years. <bg>
>
> Good luck,
>
> Terry and Sequel the techno-kitten
>
> On 6 Jul 2010 21:42:54 -0700, Harimada wrote:
>
>>Please tell me why in the future PB still have Classic and
>>NET version. For me, I a bit confused with which version
>>should must i choose. Why does not Sybase produce only one
>>PB version that could offer everything in development.
>>
>>One other thing after PB classic application migrated to
>>PB.NET, there is no other way to 'turn back' to classic
>>application.
>>Please Advise.
>
> *********************************
> Build your vocabulary while feeding the hungry
> http://www.freerice.com
> *********************************
> Newsgroup User Manual
> =====================
> TeamSybase <> Sybase employee
> Forums = Peer-to-peer
> Forums <> Communication with Sybase
> IsNull (AnswerTo (Posting)) can return TRUE
> Forums.Moderated = TRUE, so behave or be deleted
> *********************************
>
> Sequel's Sandbox: http://www.techno-kitten.com
> Home of PBL Peeper, a free PowerBuilder Developer's Toolkit.
> Version 4.0.4 now available at the Sandbox
> PB Futures updated June 25/2008
> See the PB Troubleshooting & Migration Guides at the Sandbox
> ^ ^
> o o
> =*=
jeff
Could the swing in attitude be attributed to gv'mnt PB projects drying up?
"Bruce Armstrong" <NOCANSPAM_br...@yahoo.com> wrote in message
news:p2be36db517qv23f9...@4ax.com...
> __________ Information from ESET Smart Security, version of virus
> signature database 5265 (20100709) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
>
>
>
__________ Information from ESET Smart Security, version of virus signature database 5265 (20100709) __________
The message was checked by ESET Smart Security.
fisher
you might disagree but in my opinion - none of those you've mentioned is
implemented in PB Classic.
I realize that it cannot be 100% representative, but I know no software
house that is currently going to go to PB.NET with current PB build app.
Looks like Win32 and a WinForm're going to stay for a while, Sybase
instead of delivering functionalities you mentioned on the list, made a
choice of investing ALL their resources in .NET, time will show if it
was the right choice. The worst is that current status of PB.NET could
be something really cool like few years ago ... they're just late.
On top of that I see no enh. request asking for not enhancing PB Classic
any more, I just cannot see any reason for releasing PB12 Classic.
In the mean time people will stay with PB 10.5/11 having no good reason
for upgrading for PB12.
For now there's no release/features path for PB Classic that I'd be
aware of - it's a pity, I cannot recommend anything to my managers when
asked for what new I can deliver in current environment.
These are my .02 USD and I do not expect everybody share my opinion.
Chris
Bruce Armstrong
>3) Web services need to be improved to handle newer
>standards like WSE 3.0.
Fact check of the day: WSE 3.0 is not a newer standard. It is an old
"standard". It's not actually a standard, it's an implementation
intended to meet a standard, the standard is WS-Security.
The new "standard" or - actually implementation of that standard and
additional features - is WCF. And Sybase did provide support for that
in PB12.
Brett Weaver
I really respect and appreciate the contribution that you have made to the
PB developer community for more than a decade.
I'm sure C# has all of the features you list, and by default, so does
PB.Net. because it uses visual studio. To purport that they were included
after due care and consideration of requested enhancements is a little sly,
don't you think? Or have I got it wrong and there is a serious list of PB
only enhanced capabilities included as tools in the VS environment?
In any case the majority of PB developers have no access to them because
they maintain PB code bases.
What does this mean? Well, Wallies like me who were assuring our clients
that, based on what we were hearing, PB was meeting the market and providing
a real step forward in PB12 are embarrassed. Probably our own fault I agree.
As I have said, time to stop the sniping and move on.
"Bruce Armstrong" <NOCANSPAM_br...@yahoo.com> wrote in message
news:vp1g365ihka55btd2...@4ax.com...
>
> Are you referring to 12 Classic? Because a number of the enhancements
> you are referring to were included in 12.Net:
>
> 2916 Should have some autoresize capability within PowerBuilder
> 3173 Allow IDE plug-ins to allow 3rd parties to provide features to
> enhance development process
> 3074 Collapsing IF.. END IF, FOR .. NEXT, etc
> 3002 Next Generation WIndows UI Enhancements
> 3224 Right click to jump to painters
> 3081 Collapse code in editor
> 3165 Provide code jump/link
> 3226 Powerbuilder Script Editor
> 3240 Go to Definition
> 2647 Better search capability
> 2656 search and replace
> 2583 feature rich Script editor or able to plugin any other feature
> rich script editor like UltraEdit.
> 3317 Global String Replace
> 2640 Add Interface objects to PowerBuilder 9.
> 3151 Powerscript Enhancements (most but not all of them)
> 2752 Add return type information to AutoComplete.
> 2577 Microsoft like IntelliSense
> 3296 xaml datawindow
> 2677 Extra generators for PB
> 3084 Hide full PBL path in painter window title
> 3164 Allow code change in the debugger (it allows this, but you
> have to save the modified object with a different name)
> 2491 From debugger, jump to script editor
> 2602 Support MDI tabs.
> 2567 Allow Version Control of Supporting Files
> 3160 Allow copy/paste of individual lines from output pane in IDE
> 2761 Todo List for Powerbuilder should be dockable and hide capable
> in the development environment
> 2674 Add arguments for constuctors
> 2673 parameters to constructors
> 2608 Auto Hide - System Tree, Output and Clip window similiar to
> Windows TaskBar AutoHide property
> 2718 Provide 'auto-hide' capability for the panes in the PB IDE.
> 3225 Integrate Powerbuilder as add-on to Visual Studio
> 2676 Allox the definition of supplemental constructors with
> arguments
> 3203 add the possibility to set func,event documentation directrly
> from the IDE
> 3262 Make any tabpage of the ide dockable as a dedicated view
> 3045 Ability to save source code without pass compile
> 2741 To specify the .*sr* files different than the PBL files for
> source control.
> 3143 Creation of new library should be allowed under a selected
> target in the system tree
> 3144 Create a new Library creation dialog
> 3357 Add support for Subversion (added as a result of the support
> for plug-ins, including VSTortoise)
> 2565 Get Rid of The PBL!
>
> It also looks like the enhancement database is a bit out of date. A
> number of the "under consideration" status items were included in
> earlier releases of PB.
>
> All that being said, my concern with the ISUG enhancement list is that
> it's a fairly small sampling of PowerBuilder users. The Webforms
> support for Firefox enhancment request, the second highest scoring
> enhancment request in the system of PowerBuilder, ony has 36 total
> votes.
>
> On the other hand, the Novalys annual survey has thousands of
> respondants (or at least they did in 2004, the last time I can find
> they reported the number of respondants). In the 2009 survey, 24% of
> the respondants indicated they were interested in using PB to generate
> .Net applications now, and another 35% said they would be interested
> in doing it in the future. When asked what enhacements they wanted
> most 50% indicated better web services support (delivered through WCF
> in PB 12.Net) and 49% indicated integration with .Net (once again
> delivered in PB 12.Net).
>
> On 9 Jul 2010 21:01:18 -0700, "Chris Pollach"
> <cpol...@travel-net.com> wrote:
>
>> Well I can tell you that none of my OSUG PB members ever mentioned
>>Sybase asking them about PB 12 feature direction. Looking from the ISUG
>>perspective, none of the 526 active enhancements logged against PB were
>>included in 12. I have never seen anyone in the NG's saying they were
>>asked
>>about PB 12. So, to me - I would be most interested to hear from actual PB
>>developers that were consulted. However, my bet is that other than
>>TeamSybase - the contact was very limited.
>>
>>
>>"Paul Horan[Sybase]" <phoran_remove@remove_sybase.com> wrote in message
>>news:4c371aa9$1@forums-1-dub...
Bruce Armstrong
Bruce Armstrong
Yes they should understand one another. And so would WSS4J, Rampart
and WSDP. Those are all technologies for implementing WS-Security.
They are all not obviously the same. WCF is the current impelmention
in .Net. WSE3 is out of date by about 5 years.
On 9 Jul 2010 21:28:18 -0700, "Chris Pollach"
<cpol...@travel-net.com> wrote:
>FYI ...
>
>WSE 3.0. WS-* specifications used in WCF are the same as in WSE 3.0 which
>makes those two interoperable.
>
>According to Microsoft, WSE and WCF should be able to understand each other
>without any problems
>
>
>
>"Bruce Armstrong" <NOCANSPAM_br...@yahoo.com> wrote in message
>news:nmae361n98npdfgp9...@4ax.com...
Brett Weaver
1.. PB Code was going to be able to address .Net assemblies. It cannot. Only
C# code generated from PB script can access .Net assemblies so any apps you
can't or wont (for performance reasons) convert to .Net do not have this
ability
2.. I was naive enough to think that "managed code" would mean I could write
a Web application in PB and host it on a service provider.
It appears that PB will never deliver 1.. and 2 is as far off as it was four
years ago.
I think a number of us "oldies" are pretty disappointed with the PB12
release. I have already corresponded with Sue D. about the inadvisability of
Sybase marketing merging the capabilities of the two paradigms as if the
same code base can support all of the targets and capabilities. We are all
old enough and ugly enough to bide our time and see what else comes out.
Please guys, lets move the forum back to what we would like to see in the
future
Cheers
Brett
"Bruce Armstrong" <NOCANSPAM_br...@yahoo.com> wrote in message
news:p2be36db517qv23f9...@4ax.com...
Bruce Armstrong
I guess what I'm trying to figure out is why people who are doing C/S
development wouldn't want to move to PB.Net. If you were hoping to go
the web, I don't expect you to be happy, but Sybase didn't promise
anything for that in this release.
But PB.Net has quite a number of the features that people have been
asking for for years. Why not move?
I can think of a few reasons based on some of the responses I've seen
here:
1. No support for regular MDI, just tabbed MDI.
2. No support for data pipelines
3. Little or no support for ActiveX / OLE Automation
4. Too slow to compile whille developing, can't just hit the run
button and see the app run immediately
5. Too buggy
6. A combination of the above
7. Something not on this list.
Frankly, I don't see any of these as "killer" issues.
I'm not bothered by 1 at all, I think it's just a training issue for
the end users, or perhaps a little creative effort to add some missing
or additoinal functionality.
I don't use pipelines much, and where I do it's fairly easy to "roll
my own", so I don't think 2 is a show stopper.
Item 3 has probably the biggest impact. But all I can say there is
"welcome to .Net!". Microsoft removed that capability early on,
we're just late to the party. There are .Net methods of driving
applications we typically drive with OLE Automation (e.g., Office) and
all but one of the ActiveX controls I use all have .Net versions. (The
vendor for the one that doesn't has been out of business for years).
This is where there will be a signficant rewrite effort though.
I guess I'm somewhat used to 4 from development in both Java and C#,
you have to compile (and compiile cleanly) before you can run. Some
of those IDEs offer background compilation (e.g., Eclipse) to help
lessen the impact. The problem I see here is that PB takes longer
because it goes through the emitter process before it does the C#
compile, so it takes longer than a pure C# app would to compile.
I've run into my share of #5, one that was a show stopper for a .Net
assembly implementation, but Sybase indicates that the fix is in the
upcoming EBF.
Did I hit your reasons and the reasons for the companies you know of?
On 10 Jul 2010 01:46:13 -0700, fisher
<fisher_NO@SPAM_star.wckp.lodz.pl_PLEASE> wrote:
Bruce Armstrong
C# has some of those features (parameterized constructors). But you
don't code in C# in PB.Net, you code in PowerScript. A number of
significant languages feature enhancements listed were added to
PowerScript as a result of user requests and to make it more compliant
with the CLR (parameterized constructors, interfaces, etc).
No, it's not sly to credit the IDE enhancements. The repeated
requests by customers to support state-of-the-art IDE capabilities was
one of the factors driving the decision to host PB in either Eclipse
or Visual Studio. Read some of the comments made by a number of the
Sybase folks with regard to that in this thread and others. They
could have continued their .Net efforts in the original IDE, but it
would have been difficult to provide the IDE features people were
looking for without a substantial rewrite. Moving PB.Net into Visual
Studio provided the features that people were asking for, and let
Microsoft do most of the work to implement it.
I'm all with moving on to talk about futures. But as long as Chris
continues to make outlandish statements like "none of the 526 active
enhancements logged against PB were included in 12", I'll be compelled
to address them.
FWIW, in an upcoming editorial in PBDJ I make my arguments for where
we should be going, particularly focused on delivering Silverlight
and/or HTML5 capability ASAP. I'll post a link to it as soon as it's
online.
On 10 Jul 2010 01:17:46 -0700, "Brett Weaver"
Jim O'Neil
anything on http://www.fyireporting.com/productsExamples.html (I'd
presume he'd put the BEST stuff there?) that the DW isn't already
capable of and wasn't doing 2 years ago, and it's certainly quite
behind where many of the component vendors are in terms of UX.
Look at consumers today, what excites them? iPhone, iPad, Droid. For
GenYers/Millenials this level of experience is rapidly becoming (has
become?) the norm, the minimum bar. For us BabyBoomers and even
GenXers, it seems like eye-candy, yet anything less for them is
tantamount to our green screen. Five years ago had the term UX even
been coined? yet today there are people and conferences focused on it.
Emerging developers too today come with a different set of values and
expectations. Many of them may never have built a "client" app, why
do you think WebForms has largely started to fall out of favor
vis-a-vis MVC? The model it was designed to leverage is a model that
is largely foreign to those under30. Their world too is OpenSource,
and patching together best of breed, 0.7 release software fosters
their creativity, whereas it typically scares the s* out of a 30-year
IT Pro - yet through it all Mozilla and Facebook seem pretty
successful :)
Tool vendors like Sybase and like Microsoft need to change as well.
Look at Windows Phone 7 (not Windows Mobile 7 - no such beast exists).
It's taken a similar road to PB 12 - there ain't no going back.
Putting lipstick on a pig can take you only so far, and to be honest a
large part of being successful in the business (take a cue from Apple)
is not providing what the user needs, but creating something that the
user wants.
Unfortunately, PowerBuilder has always focused on the need - and I
understand that need, it's very valid, very real, I was there. It's
an incredibly noble cause, but unfortunately others were there with
the shiny new toys - web, Flash, <insert tech here>, to lure them
away.
On 9 Jul 2010 21:35:42 -0700, "Chris Pollach"
<cpol...@travel-net.com> wrote:
>Lets just get Kim Sheffield back who wrote the DW originally. He already did
>the AmCharts thing back in 2004 - imagine what he could suggest for PB
>today - http://www.fyireporting.com/company.html
>
>
>
>"Terry Voth [TeamSybase]" <seq...@techno-kitten.com> wrote in message
>news:vt3e36tv2ct0thb0o...@4ax.com...
>> I can't give you a definitive answer, but how about so we can do UIs
>> like this:
>>
>> http://www.soluto.com
>>
>> (BTW, IMHO this is a pretty good start up manager for beta. Once the
>> Wiki gets populated more, it will be killer.)
>>
>> Looking at the program directory, it uses http://www.amcharts.com,
>> which only come in Flex, Flash, WPF and Silverlight. To me, this looks
>> like a practical use of the "swishiness" that WPF has to offer.
>>
>> No, you don't "need" this for business apps. (Soluto could have put
>> this data in a grid DataWindow.) Mind you, using the same mind set, 25
>> years ago I was arguing that mice had no place in business apps and
>> GUIs were great for graphics designers and that's it. <g> Time moves
>> on; people's expectations change. PB12 tried to get ahead of the game
>> for a change (at least ahead of the majority of user expectations),
>> instead of playing catch up. Did it jump ahead on the wrong path?
>> We'll know for sure in 25 years. <bg>
>>
>> Good luck,
>>
>> Terry and Sequel the techno-kitten
>>
>> On 6 Jul 2010 21:42:54 -0700, Harimada wrote:
>>
>>>Please tell me why in the future PB still have Classic and
>>>NET version. For me, I a bit confused with which version
>>>should must i choose. Why does not Sybase produce only one
>>>PB version that could offer everything in development.
>>>
>>>One other thing after PB classic application migrated to
>>>PB.NET, there is no other way to 'turn back' to classic
>>>application.
>>>Please Advise.
>>
Bruce Armstrong
can't believe you seriously looked at it.
"Chris Pollach" <cpol...@travel-net.com> wrote:
> No, its the extra monies and time to move the developers and
> applications to 12.Net vs keeping the applications on 12 Classic.
> Since there are no value-added application features GUI wise being on
> WPF and PB 12.NET currently introduces some instability/inconsistency,
> feature inhibits, poorer performance, etc it is not yet a viable
> platform. If you spent all the extra monies trying to negate these
> items vs implement the new business functionality that the end user
> needs there is NO way the end users will give the budget go ahead.
>
> If you do proceed to PB 12.net and cannot deliver better
> functionality plus the required business features in a reasonable time
> you will have your job on the line IMHO.
>
>
> "Bruce Armstrong" <NOCANSPAM_br...@yahoo.com> wrote in
> message news:c0kj36hca0tqnc19t...@4ax.com...
>> On 10 Jul 2010 18:17:50 -0700, "Chris Pollach"
>> <cpol...@travel-net.com> wrote:
>>
>> If the users you are referring to decide to move to a different
>> development tool and do a rewrite from scratch, then the issue wasn't
>> the time, money or tranining required.
>>
>>> Now a days, the end user controls the
>>> budget monies ... so how are you supposed to get any development
> > > dollars
>>> when you can not deliver the needed functionality on an existing
>>> application. Then try and tell them you need more migration time,
> > > extra >>time
>>> to debug and learn WPF, refactoring time, etc. I can tell you right
> > > now -
>>> you will be laughed out of the office (not to mention your job)
Bruce Armstrong
<cpol...@travel-net.com> wrote:
If the users you are referring to decide to move to a different
development tool and do a rewrite from scratch, then the issue wasn't
the time, money or tranining required.
>Now a days, the end user controls the
>budget monies ... so how are you supposed to get any development dollars
>when you can not deliver the needed functionality on an existing
>application. Then try and tell them you need more migration time, extra time
>to debug and learn WPF, refactoring time, etc. I can tell you right now -
>you will be laughed out of the office (not to mention your job)
Bruce Armstrong
Yep, a training issue. Like the ribbon toolbar in Office 2007. People
hated it until they learned to love it, and now they want their other
apps to have them too.
On 10 Jul 2010 18:17:50 -0700, "Chris Pollach"
<cpol...@travel-net.com> wrote:
>ROFL - "it's just a training issue for the end users"
>
>That is one of my prime arguments against WPF as it does not demonstrate the
>needed GUI features users are asking for, speed, dependability, performance,
>MDI, OLE Server, menu features, etc. Now a days, the end user controls the
>budget monies ... so how are you supposed to get any development dollars
>when you can not deliver the needed functionality on an existing
>application. Then try and tell them you need more migration time, extra time
>to debug and learn WPF, refactoring time, etc. I can tell you right now -
>you will be laughed out of the office (not to mention your job)
>
>
>"Bruce Armstrong" <NOCANSPAM_br...@yahoo.com> wrote in message
>news:ss5h3657adbrsnm06...@4ax.com...
Mark Maslow
"Jim O'Neil" <jim....@microsoft.com> wrote in message
news:9c7i369u9ddf1onou...@4ax.com...
> Emerging developers too today come with a different set of values and
> expectations. Many of them may never have built a "client" app, why
> do you think WebForms has largely started to fall out of favor
> vis-a-vis MVC? The model it was designed to leverage is a model that
> is largely foreign to those under30. Their world too is OpenSource,
> and patching together best of breed, 0.7 release software fosters
> their creativity, whereas it typically scares the s* out of a 30-year
> IT Pro - yet through it all Mozilla and Facebook seem pretty
> successful :)
I'm not sure what constitutes "typical". Patching together best of breed OS
software is what we 30-year IT pros have been doing in the Java world for
some years now with much success (although 0.7 releases don't generally
qualify as "best of breed" in my mind, since getting that title usually
means there is something of a track record). For me, this expectation that
certain people seem to have that a single tool should provide an entire
development and deployment environment straight out of the box is quite
bizzare.
There are two different directions that Sybase can take with PB. One is to
focus on supporting existing C/S apps in a way that adds value without
seriously changing the underlying paradigm. The other is to be a
full-fledged .NET language that integrates seamlessly into the entire .NET
environment. As stated elsewhere, this means a "disruptive" kind of change,
because the underlying paradigm is different in important ways. My
perception is that Sybase is trying to hedge its bets and have it both ways.
I just don't see how that can work. It's unfortunate - I would prefer to
simply leave our legacy PB apps alone with minor tweaks from time to time.
Doing a rewrite or even a major refactoring simply to end up with the same
functionality is not where I want to spend my time and energy, but the day
of reckoning will eventually come. Obviously we will review that state of
things at that time, but if I had to do it today, there is no question in my
mind that PB would not be part of the new solution. If we decide to go with
.NET, we'll do it all the way. We'll choose tools that were designed from
the ground up to work in that environment. We don't need a layer on top of
it to be constantly bridging different paradigms.
Bruce Armstrong
Perhaps you didn't notice, but I'm the author of that particular
enhancement request. I know what I asked for, and PB 12.Net delivered
it.
On 10 Jul 2010 17:51:17 -0700, "Chris Pollach"
<cpol...@travel-net.com> wrote:
>Hi Bruce;
>
> Are you just listing off the enhancements like "Support MDI tabs" that
>aren't even there in PB 12.net never mind PB 12 Classic webforms? Nice try
>to deflect that fact that these enhancements were for PB classic in the
>first place long before 12.Net.
>
>Again, who cares if some of these are in 12.Net as we need Win32 not WPF.
>
>Regards ... Chris
>President: OSUG / STD Inc.
>Blog: http://chrispollach.pbdjmagazine.com
>SourceForge: http://sourceforge.net/projects/stdfndclass
>
>
>
>"Bruce Armstrong" <NOCANSPAM_br...@yahoo.com> wrote in message
>news:vp1g365ihka55btd2...@4ax.com...
Bruce Armstrong
Controls? I don't know that .Net visual controls have parameterized
constructors.
http://msdn.microsoft.com/en-us/library/system.windows.forms.button.button.aspx
I'm pretty sure that XAML controls don't either.
You're thinking in PB terms. In .Net terms controls don't contain
code. Why would they need parameterized constructors?
On 10 Jul 2010 17:58:20 -0700, "Chris Pollach"
<cpol...@travel-net.com> wrote:
>The is another good point ... parameterized constructors were only partially
>implemented on a few objects. Just like PowerTip text on DW's ... what about
>all the controls? Sybase needs to cross the T's and dot the I's, otherwise
>it looks like all they care about is doing a half-ass job - not a good
>impression IMHO.
>
>
>
>"Bruce Armstrong" <NOCANSPAM_br...@yahoo.com> wrote in message
>news:cs3h369gm02i74207...@4ax.com...
Jim O'Neil
>Just for fun today in an IT technical meeting I asked the techie guys if anyone
>knew about WPF and I can tell you I was surprised to get a "deer in the
>headlights" look from the group
Then I'd have to say hire a new staff! There are many, many good
reasons to continue with PowerBuilder and not use WPF, but wouldn't it
concern you as that IT manager that your staff was oblivious to
significant other developments in the industry? and not exceptionally
recent ones!
How do they even have the capability to say 'no' when they don't know
what it is. As a consultant, why lead with a technology anyway?
Don't you lead with a concept? a design? the technology is just an
implementation detail :)
On 7 Jul 2010 18:55:17 -0700, "Chris Pollach"
<cpol...@travel-net.com> wrote:
>Hi Terry;
>
> Yes, private companies may latch on early but will the WPF momentum reach
>any critical mass in the IT industry? That is what I am waiting for. Just
>for fun today in an IT technical meeting I asked the techie guys if anyone
>knew about WPF and I can tell you I was surprised to get a "deer in the
>headlights" look from the group. Now this client has PB applications that
>look like GUI s***t (excuse my French). They say they want to rewrite them
>in .NET. So I asked them about WPF and the answer I got was the old - NO,
>just make them look like MS Office (even 2003 version) because PB cannot.
>
> Of course, I pointed this to the Power-To-The-Builder web site and
>mentioned that it was a PB developer handicap. :-)
>
>Now, look what one guy (Brad) can do with PB 11.x application GUI's. Sybase
>said they needed WPF to get further advanced yet fell way short of the GUI
>look Brad already accomplished (and my business users needed yesterday)! I
>would not mind paying good $$$ to have Brad's objects/controls native in PB
>12 Classic. Now that would be a great value in PB and customers would
>appreciate the vendor built-in support IMHO!
>
>Regards ... Chris
>President: OSUG / STD Inc.
>Blog: http://chrispollach.pbdjmagazine.com
>SourceForge: http://sourceforge.net/projects/stdfndclass
>
>
>
>"Terry Dykstra [TeamSybase]" <tddy...@forestoil.ca> wrote in message
>news:4c34a065$1@forums-1-dub...
>> Chris, while you may not see WPF in the future, I can say that the company
>> I work for most definitely is moving to WPF. Baby steps for now, but WPF
>> it is.
>>
>> --
>> Terry Dykstra (TeamSybase)
>> http://powerbuilder.codeXchange.sybase.com/
>> http://casexpress.sybase.com
>> product enhancement requests:
>> http://my.isug.com/cgi-bin/1/c/submit_enhancement
>>
>> <Chris Pollach> wrote in message
>> news:4c347941.3bf...@sybase.com...
>>> Hi Harimada;
>>>
>>> 1) 12.Net is only for WPF based .Net applications. WPF being
>>> Microsoft's "potential" replacement for Win32 (someday).
>>> 12.Net is also written to run underneath the .NET Isolated
>>> Development shell by MS - so Sybase can leverage the .NET
>>> world in the future.
>>>
>>> 2) 12 Classic is like PB 10,11,11.5 and supports Win32 as
>>> well as (.NET) WebForm, Winform, Smart Client, Assemblies,
>>> and Web Services. It does this using its own proprietary IDE
>>> that was originally developed by PowerSoft.
>>>
>>> For now, the two IDE's are disparate (separate worlds) and
>>> address different application technologies. If you are 100%
>>> sure that your organization is headed towards the MS-WPF
>>> world PB 12.NET would be the avenue to persue. If your
>>> organization still focuses on Win32 and you need the basic
>>> NET features only - PB 12 Classic is the avenue for now.
>>>
>>> You are absolutely correct though ... once you start
>>> developing in PB 12.NET or migrate and change your older PB
>>> applciations in 12.NET - there is NO going back (its a one
>>> way street)! What I am doing for the moment is developing in
>>> the Classic IDE and writing my code to work in the WPF world
>>> using the #IF macros. That way, if the organizations I
>>> develop for ever decide to hold at the Win32 technology,
>>> decide that WPF is not there cup-of-tea, or MS decides to go
>>> in another direction - I can still recover the PB
>>> applications for that business or technology direction
>>> change.
>>>
>>> Speaking with many IT people around the Canadian government,
>>> I have found NO committed direction to the WPF platform at
>>> this point in time. Many IT professionals here in Ottawa are
>>> evening questioning MS's direction on this - especially
>>> under Steve Balmers direction. I do not even know one
>>> department prototyping anything in the XAML world using
>>> VS2010 at this time. Most departments are either using
>>> VS2005 or 2008 and have no upgrade plans this year to
>>> VS2010.
>>>
>>> You also have to remember that PB 12.NET is basically
>>> version 0.0. So its bound to have some rough edges for a
>>> while until Sybase deals with enough WPF development
>>> projects to address its feature set (what ever they may be).
>>> They also need to addess its current short-comings like:
>>> CloseQuery events do not work properly, no MDI support, slow
>>> performance (IDE especially), cannot see instance variables
>>> and set them in descendants, no profiler support, etc.
>>>
>>> Now, Sybase is planning to show us a "Road Map" for PB at
>>> this years Techwave conferences starting in August. So it
>>> will be interesting to see how their future development
>>> plans play out to address your (and many others) concerns &
>>> needs.
>>>
>>> Regards ... Chris
Paul Horan[Sybase]
code" means in a .NET environment.
I would suggest reviewing the available documentation on the subject.
And PB can definitely invoke .NET assemblies. Brett, I'm not sure what
error you're seeing with that, but it has worked since 11.0 came out.
--
Paul Horan[Sybase]
http://paulhoran.ulitzer.com
"Chris Pollach" <cpol...@travel-net.com> wrote in message
news:4c37ee09@forums-1-dub...
> Hi Brett;
>
> I agree on your observations. I was falsely expecting the Beta program
> would include 12 classic. In fact I asked during CTP about this and was
> told that there would be new features. Only by the time we got to
> January/February 2010 did I realize that there was nothing coming in 12
> classic.
>
> I initially thought that "managed code" would mean no more PB runtime
> DLL's and 64 bit EXE's. I think that the ISP compatible web and what I
> call multi-browser support were spelled out quite well by many PB
> developers as one of the top requirements for PB 12. You are right ... we
> are no closer to this now than we were in 11.2. This one of the main
> reasons that many Cdn government departments have decided to go to VS.
>
> Regards ... Chris
> President: OSUG / STD Inc.
> Blog: http://chrispollach.pbdjmagazine.com
> SourceForge: http://sourceforge.net/projects/stdfndclass
>
>
>
> "Brett Weaver" <brettnspampleaseatweaversoftdotcom> wrote in message
> news:4c37d79e@forums-1-dub...
Bruce Armstrong
Just to beat this thing to death, all that WSE3 would give us is
WS-Security for SOAP services. WCF gives us that, but it's also a
full services implementation, it's not limited to SOAP. If you want
to work with REST web services, then you need WCF. And it looks like
REST is becoming a more popular method of transport than SOAP, so you
really do want WCF, not just WSE3.
On 10 Jul 2010 18:19:58 -0700, "Chris Pollach"
<cpol...@travel-net.com> wrote:
>I hope then that the WCF implementation in PB 12.net is 100% up to the
>functional MS spec.
>
>:-)
>
>
>"Bruce Armstrong" <NOCANSPAM_br...@yahoo.com> wrote in message
>news:pqvf36tkg78c214f2...@4ax.com...
Bruce Armstrong
I think that has a lot to do with it. I think there's something else
contributing to it as well. Some people seem to have a demand for all
the same capability that cutting edge technologies provide combined
with what seems to be a real reluctance to spend significant time
learning about those new technologies. There's an expectation that
PowerBuilder should be capable of providing such features without
having to change a line of code or requiring any additional knowledge
than the developer already has.
I think that's a unrealistic expectation, and one that it's
particularly conductive to the developer's long term career ambitions.
If there's one thing that constant about software development, it's
that it has an always increasing rate of change. Refusing to let go
of outdated technologies and embrace new ones ensures that you become
a dinosaur rather quickly.
In addition, the problem is that with such high expectations,
PowerBuilder was certain to fail to meet them. And the higher the
expectations the greater the crash when the product fails to meet
them.
chrispollach
Well said.
Regards ... Chris
> NET environment. As stated elsewhere, this means a
> "disruptive" kind of change, because the underlying
> paradigm is different in important ways. My perception is
> that Sybase is trying to hedge its bets and have it both
> ways. I just don't see how that can work. It's
> unfortunate - I would prefer to simply leave our legacy
> PB apps alone with minor tweaks from time to time. Doing
> a rewrite or even a major refactoring simply to end up
> with the same functionality is not where I want to spend
> my time and energy, but the day of reckoning will
> eventually come. Obviously we will review that state of
> things at that time, but if I had to do it today, there is
> no question in my mind that PB would not be part of the
> new solution. If we decide to go with ..NET, we'll do it
Paul Horan[Sybase]
feels or desires with the product. Stop extrapolating a small user
community in Canada (who probably take your lead on PB-related issues, so
they tend to "agree" with your view) to the entire PB customer base...
--
Paul Horan[Sybase]
http://paulhoran.ulitzer.com
"Chris Pollach" <cpol...@travel-net.com> wrote in message
news:4c39f363@forums-1-dub...
> That is exactly what the Canadian government is planning to do ... stay on
> 12 classic and not use WPF. If what I see here in Ottawa is the same in
> general for the PB customer base, then Sybase needs to rethink not
> enhancing 12 classic!
>
>
>
Mark Maslow
NOCANSPAM_br...@yahoo.com says...
>
> I think that has a lot to do with it. I think there's something else
> contributing to it as well. Some people seem to have a demand for all
> the same capability that cutting edge technologies provide combined
> with what seems to be a real reluctance to spend significant time
> learning about those new technologies. There's an expectation that
> PowerBuilder should be capable of providing such features without
> having to change a line of code or requiring any additional knowledge
> than the developer already has.
>
I agree. But part of the problem is that the Sybase seems to encourage
this kind of expectation with their marketing:
"Its declarative programming environment and high level of abstraction
simplifies the complexities of development, allowing developers to focus
on solving business problems instead of trying to keep up with the
myriad of new technologies, programming languages, and techniques. With
PowerBuilder, all you need is your current skill-set to do a variety of
application development"
Then there was the "write once, deploy anywhere" diagram, that seemed to
be saying that you could simply press a button and successfully redeploy
your legacy C/S app as a web application. Apparently, the marketing
folks eventually realized this was misleading, since they seem to have
removed that.
Jim O'Neil
couldn't help but add a few more observations.
Chris, I'm presuming your "well said" comment is aimed more toward
Mark's second paragraph, not the first, since you seem to be polar
opposite in terms of wanting everything in the box. Ironically,
that's what some of the more open-sourcy folks say is holding
Microsoft back too... the need to reinvent (for example,
EntityFramework vs. nHibernate) and the related reluctance of the
perceived "typical" Microsoft developer to accept something that
doesn't have a Redmond postmark on it. That's changing though, albeit
slowly (e.g., jQuery integration).
Mark, as for the approach to PB, well, I thought that was the plan for
the most part? PB12 .NET is ostensibly "full .NET" (granted not
complete based on my understanding, but what's there should be
'pure'), and PB12 Classic is the legacy stuff, and with PB12 for the
first time you have to decide which way to go. The line in the sand
has finally been drawn.
Not to misquote you, but you'd prefer to leave the legacy/brownfield
in PB12 classic, and use PB12.NET to build NEW apps, with the full
.NET paradigm, etc., and I think that was the intent. BUT there's
one twist, a catch-22, namely that the preponderance of PB activity
is on legacy apps, so would there really be that many "NEW" apps
built? thus the need to do as much as possible to pull the legacy into
the new world and resolve as much round peg/square hole as possible
automatically.
Which brings us to one of the noble, but ultimately stifling, traits
of PowerBuilder: how it bends over backwards to support previous
code. That worked fine - Win 3.1 -> Win7 and 16-bit to 64-bit (more
or less) - until there was, as you said, disruptive technology - first
web and now .NET. PB tried to bridge that gap without really
embracing the fundamental differences in the platforms. Granted,
theoretically everything should be abstractable, but in reality it
just doesn't work all that well.
What *should* be different now in PB12.NET is that you do (or should)
have an envirionment to go .NET 'all the way', you don't HAVE to do
the migration, refactoring, patching, you should be able to build the
app using the same best practices, patterns, etc. that you'd end up
doing in Visual Studio. The problem, I think, and you've mentioned it
to, that the siren song of pushing the button and getting instant
migration is always there, so having the commitment and resolve to
build the app with the new ".NET paradigm" with PB12.NET is much more
difficult to do than if you're forced to by virtue of abandoning your
code altogether for Visual Studio.
Part of me wonders if there might be more traction/credibility if
there were a bit more focus on building NEW applications in PB12 .NET,
pulling in the concepts that resonate with people building WPF
applications - like the Model-View-ViewModel design pattern, data
binding, etc. The same hoop that VB developers moving to VB.NET and
WinForm developers going to WPF had to jump on their "day of
reckoning" - and it wasn't an easy one, but it's a rite-of-passage
and inevitable.
Tyler Cruse
"I guess I'm somewhat used to 4 from development in both Java and C#,
of those IDEs offer background compilation (e.g., Eclipse) to help
lessen the impact. The problem I see here is that PB takes longer
because it goes through the emitter process before it does the C#
compile, so it takes longer than a pure C# app would to compile."
My contention is that the PB emitter is doing a very bad job of emitting c#
code. They took the "make every thing a function call" and a special PB
object type.
For example:
[Sybase.PowerBuilder.PBVariableAttribute(Sybase.PowerBuilder.VariableTypeKind.kInstanceVar,
"active_flag", null, "w_main", false, typeof(Sybase.PowerBuilder.PBBoolean),
Sybase.PowerBuilder.PBModifier.Public, "= FALSE")]
public Sybase.PowerBuilder.PBBoolean active_flag = new
Sybase.PowerBuilder.PBBoolean(false);
Should have been:
bool active_flag = false ;
[Sybase.PowerBuilder.PBVariableAttribute(Sybase.PowerBuilder.VariableTypeKind.kInstanceVar,
"fldchr", null, "w_main", "|", typeof(Sybase.PowerBuilder.PBString),
Sybase.PowerBuilder.PBModifier.Public, "= \"|\"")]
public Sybase.PowerBuilder.PBString fldchr = new
Sybase.PowerBuilder.PBString("|");
Should have been:
string fldchr = "|" ;
Note: for this example these were never referenced outside of this class so
they did not need to be public. They also were never used in a manner where
they could be set as NULL, so nullability is also not a question.
My desire would be for the emitter to generate c# that required a minimal
about of PB Runtime support and be kept after the one-time migration. Where
editing would be done at the c# level rather than doing a
migration/conversion after every change. I would like the end result be
such that with a "data window .net" like add-in to full VS, that all future
changes/mods would be done with VS c#.
Tyler Cruse
Thanks
Mark Maslow
jim....@microsoft.com says...
> What *should* be different now in PB12.NET is that you do (or should)
> have an envirionment to go .NET 'all the way', you don't HAVE to do
> the migration, refactoring, patching, you should be able to build the
> app using the same best practices, patterns, etc. that you'd end up
> doing in Visual Studio. The problem, I think, and you've mentioned it
> to, that the siren song of pushing the button and getting instant
> migration is always there, so having the commitment and resolve to
> build the app with the new ".NET paradigm" with PB12.NET is much more
> difficult to do than if you're forced to by virtue of abandoning your
> code altogether for Visual Studio.
>
> Part of me wonders if there might be more traction/credibility if
> there were a bit more focus on building NEW applications in PB12 .NET,
> pulling in the concepts that resonate with people building WPF
> applications - like the Model-View-ViewModel design pattern, data
> binding, etc. The same hoop that VB developers moving to VB.NET and
> WinForm developers going to WPF had to jump on their "day of
> reckoning" - and it wasn't an easy one, but it's a rite-of-passage
> and inevitable.
If I take the time and energy to learn and understand the .NET
framework, ecosystem and languages, why would I choose to use PB.NET for
building a brand new application? So I get to code in PowerScript
instead of C# or VB?
If I use datawindows, I can't integrate with Entity Framework or
nHibernate, or any of the other similar tools.
Every time I want to run something, I have to wait to turn the
PowerScript into C#, and then for XAML to be generated in order to
support visual inheritance, which, as a .NET developer, I don't need,
since there are other mechanisms that actually work better.
The code in all of the docs, samples, articles and blogs for tools from
MS, other vendords and OS are in C# and VB, so every time I find code on
the web that does just what I need to do, I have to translate it into
PS, which is then translated back to some rather odd form of C# when I
build.
I can generally expect a delay of at least a year - probably more -
between the time that a new version of .NET is released and the time
that the features become available in PB - if they ever do.
I could go on, but I'm sure you get the idea.
The statements that Sybase has put out tell me that their whole focus is
on keeping existing PB shops from having to make fundamental changes.
That might actually work for a while, but "have your cake and eat it
too" doesn't seem to me to be a viable long-term solution. If you want
to stay in the race, the training wheels eventually have to come off.
What value does PB add at that point?
Sybase states:
Developers no longer have to choose between using a tool they know and
learning a different tool to leverage new technology. Businesses don't
have to choose between keeping old applications running and embarking on
costly rewrites. PowerBuilder lets you have your cake and eat it, too.
With only your PowerBuilder skills and code, you can move ahead into the
future.Do it all with the tool you've always used, with the skills
you've always had.
Kevin Lindsay
> Part of me wonders if there might be more traction/credibility if
> there were a bit more focus on building NEW applications in PB12 .NET,
> pulling in the concepts that resonate with people building WPF
> applications - like the Model-View-ViewModel design pattern, data
> binding, etc. The same hoop that VB developers moving to VB.NET and
> WinForm developers going to WPF had to jump on their "day of
> reckoning" - and it wasn't an easy one, but it's a rite-of-passage
> and inevitable.
how to get, at least parts, of his 80 +pbl application into a web based
service orientated architecture, I really think it should go this way. What
we can do and learn in classic has been done, and what has been done (good
as it was) doesn't fit the way the world is going. The only way Sybase
keeps me from going full .Net (read MS Visual Studio) is to show me how to
get some use out of my PB legacy in this new world without being anchored to
the past. I need to know what I can do in pb.net and more importantly why I
should do it. When I have to go to visual studio to learn
anything/everything new, Pb just becomes a glorified code export program.
I'm not trying to minimize any of the great work you guys (and girls)
have done on pb 12 but that is the realities of my current situation. I'll
leave it to you to decide it anyone else will find, or has found, themselves
in the same place.
Kevin Lindsay
PB programmer since ver 4
Tyler Cruse
not important for business applications is just wrong. Now, it should be a
second to "functionality and performance (speed)".
The real problem in staying with PB12 Classic (Win32) is that most new
systems are now 64 bit, so the code will always have the handicap of having
to be run in the WOW emulation mode. Also, the end of 32 bit OS is in
sight.
I have no doubt that WPF ( or the Silverlight subset) will be the norm at
some point in the near future. Also, we all will have to be more aware of
threading and other ways to make the UI more responsive. It would have been
nice if the PB verb "postevent" would have been implemented as a "background
worker" call, but would require some cleaver implementation.
Brad Wery [TeamSybase]
most likely newing up a new bool and assigning it a value of false, this
is very similar to what PB is doing.
As for PB generating crystal clear readable C# code... I'm not sure why
they would want to do that. I don't think they are in the business of
converting their customer base to the competition.
My desire would be to compile directly to IL and forget about C#. That
would be a better solution.
Adrian Galvan
MDI, all we expect to reuse is our NVO's, business logic that is, we are
currently thinking if it is at all worth the time to go ahead with a
rewrite in PB .Net, given how slow it is to develop with it, or go ahead
and take the hit and rewrite with visual studio.
So far we have no reason to stay with PB we might wait for PB 13 .Net
and see if that hits a turning point.
Regards,
Adrian
Jerry Siegel [TeamSybase]
http://www.sybase.com/techwave
Shameless plug: c'mon over, kid. The first day is free!
Report Bugs to Sybase: http://case-express.sybase.com/cx/welcome.do
Product Enhancement Requests:
http://my.isug.com/cgi-bin/1/c/submit_enhancement
On 7/16/2010 1:38 PM, Kevin Lindsay wrote:
> Adrian, it sounds like you and I should be having a beer (or three)
> together.
>
> The question I'm struggling with is can pb.net even play nicely in this
> world of delgates, MVVM patterns, etc? That's what I need Sybase to be
> screaming from the roof tops. .net is massive, and a huge pardigm shift
> from the pb classic way of thinking. Since Sybase admits, it's not
> completely there yet .net wise with PB, help me understand what I can
> do, now. I know they are trying, but with the exception of seeing a new
> WPF style window or two the message doesn't seem to be getting through.
> .net appears to force you to think about things at a far more granular
> level (than Pb devs are used to), and if PB wants to remain hiding the
> details behind the curtain I'm fine with that but... I'll need some
> guidance to see how to go from the .net detail level to PB generic level
> and back again. Maybe PB can do it already and once I get some more .net
> knowledge under my belt I'll see what's possible. Right now however,
> nothing I've learned to this point makes me go "oh. that's just like
> doing (x) in pb classic". So I keep asking myself "then what does PB
> give me?".
>
> "Adrian Galvan" <agalvan_...@audisys.com> wrote in message
> news:4c3f8793@forums-1-dub...
Kevin Lindsay
together.
The question I'm struggling with is can pb.net even play nicely in this
world of delgates, MVVM patterns, etc? That's what I need Sybase to be
screaming from the roof tops. .net is massive, and a huge pardigm shift
from the pb classic way of thinking. Since Sybase admits, it's not
completely there yet .net wise with PB, help me understand what I can do,
now. I know they are trying, but with the exception of seeing a new WPF
style window or two the message doesn't seem to be getting through. .net
appears to force you to think about things at a far more granular level
(than Pb devs are used to), and if PB wants to remain hiding the details
behind the curtain I'm fine with that but... I'll need some guidance to see
how to go from the .net detail level to PB generic level and back again.
Maybe PB can do it already and once I get some more .net knowledge under my
belt I'll see what's possible. Right now however, nothing I've learned to
this point makes me go "oh. that's just like doing (x) in pb classic". So I
keep asking myself "then what does PB give me?".
"Adrian Galvan" <agalvan_...@audisys.com> wrote in message
news:4c3f8793@forums-1-dub...
Adrian Galvan
is a bunch of us... maybe we should get together on a cruise ship and
have a bunch of beers...
I'm too new at this PB .Net thing still... But from what I've seen it
doesn't look good... I don't know if PB .Net will play well with the
rest of the world... And I don't see any improvements over other
languages, and it's not even a complete .Net implementation, I believe
it's not on FrameWork 4. PB has a lot of catching up to do and we will
see what can be done between now and when PB 13 hits the market which I
believe is a good 18 months away... We had put off .Net waiting for PB
12 .Net and we are a little disappointed... I know a lot of people put
in a lot of work on going .Net and we appreciate all your hard work, but
we are still not there.
I'm all ears on what will be said <read roadmap> at TechWave...
Regards,
Adrian
Adrian Galvan
Regards,
Adrian
El 15/07/2010 10:15 p.m., Chris Pollach escribió:
> Yep ... 13 should be lucky. :-)
>
> Exactly one of my key points ... what new UI features, development aids
> (like SMTP), development team productivity, etc does 12 classic or
> 12.net bring to the table? In a small way 12.NET does add some UI
> potential but its negated with WPF handicaps, slow IDE, no team tools, etc
>
>
> "Adrian Galvan" <agalvan_...@audisys.com> wrote in message
> news:4c3f8793@forums-1-dub...