Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #33005 > unrolled thread

Things have 'moved on' apparently

Back to article view | Back to comp.lang.java.programmer

Contents

  Things have 'moved on' apparently Eternal Hope <laughingspam99@gmail.com> - 2015-11-06 12:32 +0000
    Re: Things have 'moved on' apparently Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-11-06 08:25 -0800
      Re: Things have 'moved on' apparently Eric Douglas <e.d.programmer@gmail.com> - 2015-11-06 12:02 -0800
        Re: Things have 'moved on' apparently Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-06 19:46 -0500
          Re: Things have 'moved on' apparently Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-07 17:21 +0000
            Re: Things have 'moved on' apparently Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-07 12:50 -0500
          Re: Things have 'moved on' apparently Eric Douglas <e.d.programmer@gmail.com> - 2015-11-09 05:37 -0800
            Re: Things have 'moved on' apparently Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 09:00 -0500
            Re: Things have 'moved on' apparently Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-09 14:56 +0000
            Re: Things have 'moved on' apparently Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-09 19:25 +0000
        Re: Things have 'moved on' apparently Arne Vajhøj <arne@vajhoej.dk> - 2015-11-07 21:57 -0500
      Re: Things have 'moved on' apparently Arne Vajhøj <arne@vajhoej.dk> - 2015-11-07 22:02 -0500
        Re: Things have 'moved on' apparently leif.roar@dimnakorr.com - 2015-11-08 02:00 -0600
          Re: Things have 'moved on' apparently Arne Vajhøj <arne@vajhoej.dk> - 2015-11-08 08:44 -0500
            Re: Things have 'moved on' apparently leif.roar@dimnakorr.com - 2015-11-08 13:08 -0600
          Re: Things have 'moved on' apparently Robert Klemme <shortcutter@googlemail.com> - 2015-11-08 18:54 +0100
            Re: Things have 'moved on' apparently Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-08 21:12 +0000
              Re: Things have 'moved on' apparently Arne Vajhøj <arne@vajhoej.dk> - 2015-11-08 17:05 -0500
                Re: Things have 'moved on' apparently Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-08 23:24 +0000
                  Re: Things have 'moved on' apparently Arne Vajhøj <arne@vajhoej.dk> - 2015-11-08 19:40 -0500
                    Re: Things have 'moved on' apparently Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-08 21:32 -0500
                      Re: Things have 'moved on' apparently Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-09 15:15 +0000
        Re: Things have 'moved on' apparently Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-11-08 12:10 -0800
          Re: Things have 'moved on' apparently Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-08 16:00 -0500
          Re: Things have 'moved on' apparently Arne Vajhøj <arne@vajhoej.dk> - 2015-11-08 16:51 -0500
    Re: Things have 'moved on' apparently Jan Burse <janburse@fastmail.fm> - 2015-11-08 00:55 +0100
    Re: Things have 'moved on' apparently Arne Vajhøj <arne@vajhoej.dk> - 2015-11-07 21:28 -0500
      Re: Things have 'moved on' apparently Arne Vajhøj <arne@vajhoej.dk> - 2015-11-07 21:36 -0500
    Re: Things have 'moved on' apparently leif.roar@dimnakorr.com - 2015-11-08 02:12 -0600
    Re: Things have 'moved on' apparently askfor <askfor@nowhere.net> - 2015-11-09 18:02 +0100
    Re: Things have 'moved on' apparently Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-11-10 22:32 -0800
      Re: Things have 'moved on' apparently Eternal Hope <laughingspam99@gmail.com> - 2015-11-11 07:52 +0000
        Re: Things have 'moved on' apparently ross.finlayson@gmail.com - 2015-11-19 23:28 -0800

Page 1 of 2  [1] 2  Next page →

#33005 — Things have 'moved on' apparently

Since retiring I have tried to keep up with what's going on in the 'real 
world' I'm not entirely sure what world this is but there we are, digress.

Anyway. I've just been talking to a guy who invests in IT start ups, 
mainly financial stuff and I was somewhat taken aback when he said ...

"Of course, things have moved on from Java now"

Moved on to what I asked

"Python said he"

"That's what all the kids in the city are using these days"

Is it?

I have messed around with Python, well it's OK but is this really a 
robust enough language to be writing financial systems in?

It's a rhetorical question

Do I now have to throw away my significant investment in Java to learn 
Python. Am I a dinosaur :-(

-- 
Laughing Spam Fritter

[toc] | [next] | [standalone]

#33006

In article <n1i6go$btr$1@dont-email.me>,
 Eternal Hope <laughingspam99@gmail.com> wrote:

> Since retiring I have tried to keep up with what's going on in the 'real 
> world' I'm not entirely sure what world this is but there we are, digress.
> 
> Anyway. I've just been talking to a guy who invests in IT start ups, 
> mainly financial stuff and I was somewhat taken aback when he said ...
> 
> "Of course, things have moved on from Java now"
> 
> Moved on to what I asked
> 
> "Python said he"
> 
> "That's what all the kids in the city are using these days"
> 
> Is it?
> 
> I have messed around with Python, well it's OK but is this really a 
> robust enough language to be writing financial systems in?
> 
> It's a rhetorical question
> 
> Do I now have to throw away my significant investment in Java to learn 
> Python. Am I a dinosaur :-(

Based on my recent job hunt, I'd say Java is holding steady as an older 
language.  It's not going away but nobody is rushing for the latest 
Oracle upgrades either.  It still has a bad reputation for easily 
becoming bloated with libraries and add-ons.

Python is the hot new language where PHP and Ruby once ruled.  Some 
powerful scientific and data analysis packages use it too.  These 
languages aren't well suited for large apps so they're not competing 
with all types of Java uses.

C++11 is what's growing in the large apps category.  Problems of "who 
owns this pointer" have been addressed so it's a little less prone to 
memory leaks and mysterious runtime crashes.  A few legacy WTFs are 
cleaned up too.

-- 
I will not see posts from astraweb, theremailer, dizum, or google
because they host Usenet flooders.

[toc] | [prev] | [next] | [standalone]

#33007

On Friday, November 6, 2015 at 11:35:27 AM UTC-5, Kevin McMurtrie wrote:
> Based on my recent job hunt, I'd say Java is holding steady as an older 
> language.  It's not going away but nobody is rushing for the latest 
> Oracle upgrades either.  It still has a bad reputation for easily 
> becoming bloated with libraries and add-ons.
> 
> Python is the hot new language where PHP and Ruby once ruled.  Some 
> powerful scientific and data analysis packages use it too.  These 
> languages aren't well suited for large apps so they're not competing 
> with all types of Java uses.
> 
> C++11 is what's growing in the large apps category.  Problems of "who 
> owns this pointer" have been addressed so it's a little less prone to 
> memory leaks and mysterious runtime crashes.  A few legacy WTFs are 
> cleaned up too.

I think Java is only as bloated as you make it and I believe Project Jigsaw slated for Java 9 is supposed to reduce bloat.  I'm not sure what you mean about the Oracle upgrades.  I haven't had any issues with upgrades.  If anything my code seems to run better on the newer Java, though you don't need to rush to the latest if you're not concerned with the changes they've made for security.  Everyone makes security changes, Windows pushes those out every week.

All I know about Python is there's a little script required for our Blender software.  What else is it good for?  I thought it did web stuff but I thought everyone was using HTML5/CSS/Javascript/PHP for web now.  It's hard to keep up with web.  I know at least one site still running Java Applets, and at least one site still running ActiveX.

Does Python run local applications?  Does it do anything Java can't?  Do people still use C++ for local business applications?  I thought most were going to Java, with some still running C#.  I haven't found much Java can't do.  I can name a dozen or two programming languages off the top of my head, it's hard to keep up with what the languages are much less what they're good for.  python.org says Google uses Python, but we use Google Apps with the Google Java API, and we recently started writing Google Script.  How many languages do you suppose they use at Google?

It's always something.  You have to know framework code like Java or C#, and you have to know application code like Microsoft Dynamics or PeopleSoft, and they want to go mobile so you learn Android Java and Objective C.  How many companies still run JCL and COBOL?

To build a successful resume, learn Java, Android Java, JUnit, Objective C, C, C++, C#, BASIC, VB, VB.NET, Python, Jython, VBScript, Javascript, jQuery, PHP, HTML, CSS, JSP, ASP, ASP.NET, XML, XSL, XSLT, SQL, PL/SQL, Unix shell, Powershell, AJAX, JSON, SVG, Ruby, Ruby on Rails, GRails, Groovy, Spring, JCL, COBOL, BASIC, FORTRAN, CICS, DB2, RPG, Perl, SOAP, Tomcat, and more.  This is just most of the languages/framewords/buzzwords I've heard of and know anything about.  Of course you're not likely to know all of these much less be an expert in them, but I've seen many ads looking for programmers who know a specific combination of at least 4 of them, and generally it's a combination no other company is likely using so good luck with that.  The tricky part is not only knowing at least the basics in every language but knowing what the best language is for every application.  I say Java is currently #1 because it is cross platform and I haven't found much if anything it can't do.

[toc] | [prev] | [next] | [standalone]

#33008

On 11/6/2015 3:02 PM, Eric Douglas wrote:
> On Friday, November 6, 2015 at 11:35:27 AM UTC-5, Kevin McMurtrie wrote:
>> Based on my recent job hunt, I'd say Java is holding steady as an older 
>> language.  It's not going away but nobody is rushing for the latest 
>> Oracle upgrades either.  It still has a bad reputation for easily 
>> becoming bloated with libraries and add-ons.
>>
>> Python is the hot new language where PHP and Ruby once ruled.  Some 
>> powerful scientific and data analysis packages use it too.  These 
>> languages aren't well suited for large apps so they're not competing 
>> with all types of Java uses.
>>
>> C++11 is what's growing in the large apps category.  Problems of "who 
>> owns this pointer" have been addressed so it's a little less prone to 
>> memory leaks and mysterious runtime crashes.  A few legacy WTFs are 
>> cleaned up too.
> 
> I think Java is only as bloated as you make it and I believe Project Jigsaw slated for Java 9 is supposed to reduce bloat.  I'm not sure what you mean about the Oracle upgrades.  I haven't had any issues with upgrades.  If anything my code seems to run better on the newer Java, though you don't need to rush to the latest if you're not concerned with the changes they've made for security.  Everyone makes security changes, Windows pushes those out every week.
>

True to a certain extent.  However, Java is by its design more bloated
than languages which compile to native code.  OTOH, Java is more
portable across platforms, where that is important.

> All I know about Python is there's a little script required for our Blender software.  What else is it good for?  I thought it did web stuff but I thought everyone was using HTML5/CSS/Javascript/PHP for web now.  It's hard to keep up with web.  I know at least one site still running Java Applets, and at least one site still running ActiveX.
> 
> Does Python run local applications?  Does it do anything Java can't?  Do people still use C++ for local business applications?  I thought most were going to Java, with some still running C#.  I haven't found much Java can't do.  I can name a dozen or two programming languages off the top of my head, it's hard to keep up with what the languages are much less what they're good for.  python.org says Google uses Python, but we use Google Apps with the Google Java API, and we recently started writing Google Script.  How many languages do you suppose they use at Google?
> 
Yes, Python can run local applications.  Whether it can do things Java
can't is really immaterial.  Each language has its advantages and
disadvantages; Python may just be able to do something *more
efficiently* than Java.

> It's always something.  You have to know framework code like Java or C#, and you have to know application code like Microsoft Dynamics or PeopleSoft, and they want to go mobile so you learn Android Java and Objective C.  How many companies still run JCL and COBOL?
> 

COBOL is still the most commonly used language in the world, with an
estimated > 2B LOC created annually.  While it is not used for web
applications, it is used extensively in financial applications such as
government, banking and insurance.

And JCL is the most commonly used language on IBM-compatible mainframes,
used by most large companies in the world.

> To build a successful resume, learn Java, Android Java, JUnit, Objective C, C, C++, C#, BASIC, VB, VB.NET, Python, Jython, VBScript, Javascript, jQuery, PHP, HTML, CSS, JSP, ASP, ASP.NET, XML, XSL, XSLT, SQL, PL/SQL, Unix shell, Powershell, AJAX, JSON, SVG, Ruby, Ruby on Rails, GRails, Groovy, Spring, JCL, COBOL, BASIC, FORTRAN, CICS, DB2, RPG, Perl, SOAP, Tomcat, and more.  This is just most of the languages/framewords/buzzwords I've heard of and know anything about.  Of course you're not likely to know all of these much less be an expert in them, but I've seen many ads looking for programmers who know a specific combination of at least 4 of them, and generally it's a combination no other company is likely using so good luck with that.  The tricky part is not only knowing at least the basics in every language but knowing what the best language is for every application.  I say Java is currently #1 because it is cross platform and I haven't found much if anything it can't do.
> 

Not realistic in the real world.  Better is to become an expert at one
language.  Smart potential employers/clients know one person cannot be
an expert in all of these.

It all depends on what your target audience is.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#33011

On Fri, 06 Nov 2015 19:46:43 -0500, Jerry Stuckle wrote:

> COBOL is still the most commonly used language in the world, with an
> estimated > 2B LOC created annually.  While it is not used for web
> applications, it is used extensively in financial applications such as
> government, banking and insurance.
>
Are there any estimates of how much of this is MicroFocus COBOL?  
I'd have thought these may be a fair bit of this since of you'rew 
ditching mainframes on favour of *NIX boxes, moving existing COBOL code 
to MicroFocus is probably the least-effort port.

RM COBOL?

...or is this only for mainframes?
 
> And JCL is the most commonly used language on IBM-compatible mainframes,
> used by most large companies in the world.
> 
I've seen it and didn't understand it. I remember using SPFFY a very long 
time ago and thought it easily the worst interactive environment I've 
seen. Yes, much worse than VME/B SCL or OS/400 CL - which are 
surprisingly similar in the way they work.

However there well may be more UNIX/Linux shell script out there than JCL. 
Got any numbers on that?
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#33012

On 11/7/2015 12:21 PM, Martin Gregorie wrote:
> On Fri, 06 Nov 2015 19:46:43 -0500, Jerry Stuckle wrote:
> 
>> COBOL is still the most commonly used language in the world, with an
>> estimated > 2B LOC created annually.  While it is not used for web
>> applications, it is used extensively in financial applications such as
>> government, banking and insurance.
>>
> Are there any estimates of how much of this is MicroFocus COBOL?  
> I'd have thought these may be a fair bit of this since of you'rew 
> ditching mainframes on favour of *NIX boxes, moving existing COBOL code 
> to MicroFocus is probably the least-effort port.
> 
> RM COBOL?
> 
> ...or is this only for mainframes?
>

I haven't seen a breakout by type.  But virtually every financial
institution, insurance company, U.S. governments (and a lot of foreign
ones) and more use COBOL.  Some of this is historical, but much has to
do with the handling of floating point numbers - decimal values can be
computed exactly to as many places as (reasonably) wanted.  No
float/double rounding errors.

For instance, it's not unusual to have a top limit of 999B, computed to
six or eight decimal places.  That's accuracy to 18 or 20 digits -
something you can't get with a 32 bit float.

>> And JCL is the most commonly used language on IBM-compatible mainframes,
>> used by most large companies in the world.
>>
> I've seen it and didn't understand it. I remember using SPFFY a very long 
> time ago and thought it easily the worst interactive environment I've 
> seen. Yes, much worse than VME/B SCL or OS/400 CL - which are 
> surprisingly similar in the way they work.
> 
> However there well may be more UNIX/Linux shell script out there than JCL. 
> Got any numbers on that?
>  
> 

No, I don't.  I just know that it's a huge conversion to go from an IBM
mainframe OS to Unix/Linux.  Since companies don't typically buy/lease
huge amounts of computing power, disk space, etc. than they need, to
switch they basically need to duplicate their existing hardware and
databases, then start recompiling source code (and recreating programs
whose source code may have been lost over the years - it happens!).
That plus the additional programmers to perform the conversion, often
taking two years or more, makes it a very expensive project.

As a result, there's still a lot of JCL out there, and more being
written every day.  Whether it exceeds shell scripts, I don't know.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#33039

On Friday, November 6, 2015 at 7:47:04 PM UTC-5, Jerry Stuckle wrote:
> COBOL is still the most commonly used language in the world, with an
> estimated > 2B LOC created annually.  While it is not used for web
> applications, it is used extensively in financial applications such as
> government, banking and insurance.
> 
> And JCL is the most commonly used language on IBM-compatible mainframes,
> used by most large companies in the world.
> 
I wasn't sure how much of that COBOL code still existed or how much has already been rewritten.  My first programming job was 16 years ago, with one of the largest retailers in the world.  They had a backend process which imported nightly data from stores and ran it through some COBOL programs using JCL.  Then we took that data and uploaded it to the Unix server which had shell scripts and SQR accessing an Oracle database for a PeopleSoft application.

> 
> Not realistic in the real world.  Better is to become an expert at one
> language.  Smart potential employers/clients know one person cannot be
> an expert in all of these.
> 
> It all depends on what your target audience is.

Of course it's not realistic to attempt to become an expert in dozens of languages, but it's also not realistic to just be an expert in one language.  Every Java Programmer ad I've come across was looking for someone who also knows another language.  The last one specifically wanted a Java developer who also knows Javascript, jQuery, Spring, XML, SOAP, Tomcat.  They didn't care how well I knew Java if I didn't already know jQuery even though I could teach myself jQuery within a week.

[toc] | [prev] | [next] | [standalone]

#33041

On 11/9/2015 8:37 AM, Eric Douglas wrote:
> On Friday, November 6, 2015 at 7:47:04 PM UTC-5, Jerry Stuckle wrote:
>> COBOL is still the most commonly used language in the world, with an
>> estimated > 2B LOC created annually.  While it is not used for web
>> applications, it is used extensively in financial applications such as
>> government, banking and insurance.
>>
>> And JCL is the most commonly used language on IBM-compatible mainframes,
>> used by most large companies in the world.
>>
> I wasn't sure how much of that COBOL code still existed or how much has already been rewritten.  My first programming job was 16 years ago, with one of the largest retailers in the world.  They had a backend process which imported nightly data from stores and ran it through some COBOL programs using JCL.  Then we took that data and uploaded it to the Unix server which had shell scripts and SQR accessing an Oracle database for a PeopleSoft application.
> 
>>
>> Not realistic in the real world.  Better is to become an expert at one
>> language.  Smart potential employers/clients know one person cannot be
>> an expert in all of these.
>>
>> It all depends on what your target audience is.
> 
> Of course it's not realistic to attempt to become an expert in dozens of languages, but it's also not realistic to just be an expert in one language.  Every Java Programmer ad I've come across was looking for someone who also knows another language.  The last one specifically wanted a Java developer who also knows Javascript, jQuery, Spring, XML, SOAP, Tomcat.  They didn't care how well I knew Java if I didn't already know jQuery even though I could teach myself jQuery within a week.
> 

I didn't say you should learn just one language - just that you should
be an expert in one language.  Familiarity with other languages is
always good.

Over the last nearly 50 years I've been programming, I've forgotten more
languages that many people ever learn - many you've probably never heard
of.  But of the more than 20 languages I've learned over time, I can
only really claim to ever have been really proficient in a few.  Java
was one of them close to 20 years ago, but I haven't used it much since.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#33043

On Mon, 09 Nov 2015 05:37:40 -0800, Eric Douglas wrote:

> I wasn't sure how much of that COBOL code still existed or how much has
> already been rewritten.
>
If its old and complex code that has been extensively patched, which 
describes a lot of the core code in banks, it can be remarkably resistant 
to replacement simply because nobody really understands it.

Back in the day, application documentation at all levels was hand-written 
or typescript, supplemented by hand-drawn record layouts and flow-charts. 
All too often this stuff wasn't updated or got lost, so the only up to 
date documentation was the source code, which was often badly written, 
uncommented or worse. Examples:

1) At my first site, the tape library index, which the operators relied 
on didn't even have up to date source. It was assembler, had been hand-
patched in memory to make it work and the result saved to tape. Then, 
some time later, the source had been lost.   

2) I was once faced with a bought-in COBOL accounting suite in which the 
first FD was called MT01, the first record in that was called MT02, the 
first data item in the record was called MT03 and so on through two or 
three tape files, followed by CRxx for card input, TRxx for paper tape 
and LPxx for the printer.  All procedure division paragraphs had a six 
digit numeric name (not in order). Sections? What's a section? And it 
used ALTER statements to switch from the default card input to paper 
tape. Comments? What are they? Of course, it was a complete waste of 
money. We junked it and wrote an equivalent suite from scratch.

3) that suite also had a page of assembler whose only comments was "End 
of Month Date. Works until Feb 2100". Apart from the subroutine name 
there were no labels: the whole thing was written using relative jumps 
and register-to-register operations. We knew what it did: you gave it 
today's date as ddmmyy and it returned the last day of the month in the 
same format, e.g. give it 091115 and it would return 301115, and it 
honoured leap years. Now out shop was pretty hot at assembler, but none 
of us could follow this mess through more than 10-12 instructions.
 
4) Another site I worked on as a programmer had a complete separation 
between the systems analysts and programmers. Every so often they'd come 
down with code-level documentation for bug fixes or enhancements. We 
never saw any higher level documentation. Worse yet, the analysts never 
kept documentation: once a change had been signed off, they shredded it.

Back in the day, this sort of thing was pretty much the norm and yes, 
I've worked on banking software so I know they weren't much different.

Now think that some of these systems were written for the first 
generations of IBM System/360 (which were first delivered in 1965), or 
possibly ported from the earlier IBM 1400 , and have been upgraded ever 
since, from tape or ISAM files, to IMS databases and from card input to 
cheque-reader or green-screen online input and finally to RDBMS. Are you 
surprised that they are still COBOL (and maybe even still a bit of 
assembler) and that nobody understands them well enough to do anything 
but patch the core systems as little as possible? New requirements get 
implemented by adding layers of subsidiary code that pulls the data it 
needs out of the core system, does what is needed, and merges it back 
into the database. 

> My first programming job was 16 years ago, with
> one of the largest retailers in the world.  They had a backend process
> which imported nightly data from stores and ran it through some COBOL
> programs using JCL.  Then we took that data and uploaded it to the Unix
> server which had shell scripts and SQR accessing an Oracle database for
> a PeopleSoft application.
>
Yep, sounds like what I've seen in a number of places. The COBOL was 
still there because there was nobody left who understood it well enough 
to rewrite or replace it. 

Or some PHB thought he could save some money on office space by shredding 
all that old documentation "that nobody needs any more".
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#33056

On Mon, 09 Nov 2015 15:08:13 +0000, Stefan Ram wrote:

>   (I am giving courses based on my own course notes in Java, JavaScript,
>   C, C++, C#, VBA, SQL and Android programming).
>
I'm tempted to say that the next language to learn after your main 
programming language (one or two of Java, C, C++) should be SQL. 

Why? Because, if a project involves an RDBMS, a programmer or designer 
who understands SQL and can normalise data, create a schema and can sort 
out DBMS performance issues is a hell of a lot more valuable than one who 
can't. I've lost track of the jobs where I ended up fixing the DB as part 
of my technical design/programming role. 

Don't forget, too, that its not too uncommon to find that the DBMS 
supplier's proprietary consultants will know less than you do about 
finding and fixing performance bottlenecks.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#33016

On 11/6/2015 3:02 PM, Eric Douglas wrote:
> All I know about Python is there's a little script required for our
> Blender software.  What else is it good for?  I thought it did web
> stuff but I thought everyone was using HTML5/CSS/Javascript/PHP for
> web now.  It's hard to keep up with web.  I know at least one site
> still running Java Applets, and at least one site still running
> ActiveX.

A large portion of Python work is for web.

Popular stuff includes Django MVC framework, Plone CMS etc..

Some sites known to use python:

Instagram (Django)
Pinterest (Django)
FBI (Plone)
UN (Plone)
Youtube (other)

HTML/CSS/JS client side still requires something server side.

> Does Python run local applications?

Yes.

Google web crawler is supposedly written in Python.

A lot of sysadms that need to to significant scripting are
switching to Python.

>                                     Does it do anything Java can't?

Almost all languages can do almost anything.

But Python and Java are two very different languages, so you may
prefer one over the other for a specific case.

> Do people still use C++ for local business applications?

If you have real time requirements yes. Otherwise I think it
is very rare today.

Arne

[toc] | [prev] | [next] | [standalone]

#33017

On 11/6/2015 11:25 AM, Kevin McMurtrie wrote:
> Based on my recent job hunt, I'd say Java is holding steady as an older
> language.  It's not going away but nobody is rushing for the latest
> Oracle upgrades either.  It still has a bad reputation for easily
> becoming bloated with libraries and add-ons.

Most Java EE projects tend to end up including a rather large number
of libraries.

But what is the alternative? Writing the stuff one self? That does
not sound better to me!

Which could somehow be phrased as: it is bad to have a ton of libraries
but it is even worse to not have a ton of libraries.

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#33023

Arne Vajhøj <arne@vajhoej.dk> wrote:
> 
> Most Java EE projects tend to end up including a rather large number
> of libraries.
> 
> But what is the alternative? Writing the stuff one self? That does
> not sound better to me!
> 
> Which could somehow be phrased as: it is bad to have a ton of libraries
> but it is even worse to not have a ton of libraries.

Sometimes, not often, but sometimes, it _is_ better to write the stuff
yourself. I once saw a project that included Ant as a dependency just
to use a trivial utility method (it was either String manipulation or
Date parsing. I forget which.)

On a more general note, though, it would be preferrable to have a 
dependency system that supported dependency on function rather than,
as we have in the java biosphere today, only dependency on name. So 
rather than say "I'm library X, version 2, and I require library Y 
version 3.3 and library Z version 5.0" you could say "I'm library X, 
and I require libraries that provide Foo and Bar functionalities,
_for instance_ library Y 3.3 and library Z version 5.0."

That way, you could more easily consoldiate transitive dependencies
and not have to pull in three different logging frameworks and two
different JSON parsers. (To really make this work well, you'd
probably need some kind of in-language support for type aliasing,
though.)

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#33025

On 11/8/2015 3:00 AM, leif.roar@dimnakorr.com wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> Most Java EE projects tend to end up including a rather large number
>> of libraries.
>>
>> But what is the alternative? Writing the stuff one self? That does
>> not sound better to me!
>>
>> Which could somehow be phrased as: it is bad to have a ton of libraries
>> but it is even worse to not have a ton of libraries.

> On a more general note, though, it would be preferrable to have a
> dependency system that supported dependency on function rather than,
> as we have in the java biosphere today, only dependency on name. So
> rather than say "I'm library X, version 2, and I require library Y
> version 3.3 and library Z version 5.0" you could say "I'm library X,
> and I require libraries that provide Foo and Bar functionalities,
> _for instance_ library Y 3.3 and library Z version 5.0."
>
> That way, you could more easily consoldiate transitive dependencies
> and not have to pull in three different logging frameworks and two
> different JSON parsers. (To really make this work well, you'd
> probably need some kind of in-language support for type aliasing,
> though.)

Interesting idea.

But I fear that it would not be easy to implement.

I see at least two potential problems:
* incompatible API's requiring changes in the calling code
* difficulties in describing what you need sufficient precise

Arne

[toc] | [prev] | [next] | [standalone]

#33027

Arne Vajhøj <arne@vajhoej.dk> wrote:
> 
> Interesting idea.
> 
> But I fear that it would not be easy to implement.
> 
> I see at least two potential problems:
> * incompatible API's requiring changes in the calling code
> * difficulties in describing what you need sufficient precise
> 
> Arne

Certainly, but the main benefit of such a system is that you could
write wrappers for dependencies.

Say you use two libraries A and B. A has a requirement for "Foo 
XML parsing", such as provided by the library FooXML_1.0.4.jar, 
while B has a requirement for "Bar XML Parsing" as provided by
BarXML_2.3.jar. Rather than include two XML parsers, you can
just write a small wrapper FooBarWrapper.jar which provides
the "Foo XML parsing" functionality, implemented by calling the 
BarXML implementation.

Sure, there are dangers here in clients relying on implicit 
behaviour from a given library, but at least you'd have the
_option_ to consolidate similar nodes in your dependency 
graph. 

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#33026

On 08.11.2015 09:00, leif.roar@dimnakorr.com wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:

>> Which could somehow be phrased as: it is bad to have a ton of libraries
>> but it is even worse to not have a ton of libraries.
>
> Sometimes, not often, but sometimes, it _is_ better to write the stuff
> yourself. I once saw a project that included Ant as a dependency just
> to use a trivial utility method (it was either String manipulation or
> Date parsing. I forget which.)

There are also other cases where it is better to bite the bullet and 
write stuff yourself, even if it is complicated.  That happened to us 
once and the reason was the awful quality of the library used and the 
slowness of the provider to come up with bug fixes.

Bottom line: you have to die one death or another (is this also an 
English phrase btw.?) and there is no general rule - just the usual 
trade offs.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#33030

On Sun, 08 Nov 2015 18:54:07 +0100, Robert Klemme wrote:

> There are also other cases where it is better to bite the bullet and
> write stuff yourself, even if it is complicated.
>
Been there, done that.

In this case the offending functions were the malloc and B-tree modules 
in the C standard library for DEC's Alpha servers running TrueUNIX.

The root problem was that the OS was Mach-based and the implementation 
seemed to use a single-threaded process to implement each low level clib 
function: at least, we found this problem in several parts of the OS. 
Maybe this is the main reason that Mach message-passing micro-kernel 
architectures have largely disappeared, but I digress...
 
The effect was that, because the btree routine used three chunks of 
memory for each node (IIRC one for key, one for data, one for the three 
pointers), so that lookups (which added unknown nodes to the tree) bottle-
necked on the malloc() process with three calls per node added. We needed 
something like 7,000 lookups/sec but couldn't break 800.

So I rewrote the btree functions to use only one struct per node, which 
gave an immediate speedup to better than 1500 lookups/sec. 

More checks showed that now the sbrk() function that malloc() called each 
time it needed to extend process heap memory had the same problem. So, I 
changed my code to use malloc() to grab MB-sized chunks of heap space and 
and wrote an application level function that allocated btree nodes in my 
chunk of heap and asked for more when it was needed. This gave me 25,000 
looks/sec: job done!

This also showed just how important it is to have enough test data: we 
had 500,000 test data records. If we'd been using the 50 - 200 records 
I've seen a lot of projects get by with this dire performance would have 
been a nasty shock when the system went live instead of showing up at the 
start of integration testing.

> Bottom line: you have to die one death or another
>
If it isn't, it should be.

> there is no general rule - just the usual trade offs.
> 
Spot on.



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#33032

On 11/8/2015 4:12 PM, Martin Gregorie wrote:
> In this case the offending functions were the malloc and B-tree modules
> in the C standard library for DEC's Alpha servers running TrueUNIX.
>
> The root problem was that the OS was Mach-based and the implementation
> seemed to use a single-threaded process to implement each low level clib
> function: at least, we found this problem in several parts of the OS.
> Maybe this is the main reason that Mach message-passing micro-kernel
> architectures have largely disappeared, but I digress...
>
> The effect was that, because the btree routine used three chunks of
> memory for each node (IIRC one for key, one for data, one for the three
> pointers), so that lookups (which added unknown nodes to the tree) bottle-
> necked on the malloc() process with three calls per node added. We needed
> something like 7,000 lookups/sec but couldn't break 800.
>
> So I rewrote the btree functions to use only one struct per node, which
> gave an immediate speedup to better than 1500 lookups/sec.
>
> More checks showed that now the sbrk() function that malloc() called each
> time it needed to extend process heap memory had the same problem. So, I
> changed my code to use malloc() to grab MB-sized chunks of heap space and
> and wrote an application level function that allocated btree nodes in my
> chunk of heap and asked for more when it was needed. This gave me 25,000
> looks/sec: job done!

Isn't that what __mingrow was supposed to do in a more transparent way?

Arne

[toc] | [prev] | [next] | [standalone]

#33033

On Sun, 08 Nov 2015 17:05:47 -0500, Arne Vajhøj wrote:

> On 11/8/2015 4:12 PM, Martin Gregorie wrote:
>> In this case the offending functions were the malloc and B-tree modules
>> in the C standard library for DEC's Alpha servers running TrueUNIX.
>>
>> The root problem was that the OS was Mach-based and the implementation
>> seemed to use a single-threaded process to implement each low level
>> clib function: at least, we found this problem in several parts of the
>> OS. Maybe this is the main reason that Mach message-passing
>> micro-kernel architectures have largely disappeared, but I digress...
>>
>> The effect was that, because the btree routine used three chunks of
>> memory for each node (IIRC one for key, one for data, one for the three
>> pointers), so that lookups (which added unknown nodes to the tree)
>> bottle-
>> necked on the malloc() process with three calls per node added. We
>> needed something like 7,000 lookups/sec but couldn't break 800.
>>
>> So I rewrote the btree functions to use only one struct per node, which
>> gave an immediate speedup to better than 1500 lookups/sec.
>>
>> More checks showed that now the sbrk() function that malloc() called
>> each time it needed to extend process heap memory had the same problem.
>> So, I changed my code to use malloc() to grab MB-sized chunks of heap
>> space and and wrote an application level function that allocated btree
>> nodes in my chunk of heap and asked for more when it was needed. This
>> gave me 25,000 looks/sec: job done!
> 
> Isn't that what __mingrow was supposed to do in a more transparent way?
>
'locate' doesn't find __mingrow (or mingrow) in my development 
environment. The pnly references I can find are in relation to a C# 
priority queue: this all happened long before C# existed.

However, I suppose I could have used sbrk() or brk() to collect big 
chunks of heap space instead of malloc(), but the effect would have been 
minimal and in any case use of malloc() is preferred to either brk() or 
sbrk().

Malloc() is pretty transparent and, it turned out that my trick of 
building a list of pointers to large separate blocks of heap space paid 
off later. 

I should add that the Btrees (there was more than one) were used as fast 
lookups to translate large (19 byte) keys into 32 bit soft dbks: both  
ended up as dimensions in a star schema that were updated each time 
another batch of data was loaded into the datawarehouse. Since a key 
values could appear in up to three columns in the fact table, we 
preferred to use the sdbkeys there rather than the actual key values 
because doing this gave us a substantial amount of data compression in 
what was a very large data warehouse for the time. Anyway, when the 
system started up one of its first tasks was to read the dimensions and 
create Btrees from it. After the main Btree exceeded 100M key values, 
people started to complain about the start-up time. This was easy to fix: 
periodically, and as part of shutdown the lookup processes simply wrote 
each of their heap chunks to disk as binary data. Startup became much 
faster, since the processes just read each chunk back into memory as part 
of initialisation. 

It didn't matter where the chunks ended up in process address space since 
all addressing inside a chunk was a simple offset, so no translation was 
needed during the save and restore operations.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#33034

On 11/8/2015 6:24 PM, Martin Gregorie wrote:
> On Sun, 08 Nov 2015 17:05:47 -0500, Arne Vajhøj wrote:
>
>> On 11/8/2015 4:12 PM, Martin Gregorie wrote:
>>> In this case the offending functions were the malloc and B-tree modules
>>> in the C standard library for DEC's Alpha servers running TrueUNIX.
>>>
>>> The root problem was that the OS was Mach-based and the implementation
>>> seemed to use a single-threaded process to implement each low level
>>> clib function: at least, we found this problem in several parts of the
>>> OS. Maybe this is the main reason that Mach message-passing
>>> micro-kernel architectures have largely disappeared, but I digress...
>>>
>>> The effect was that, because the btree routine used three chunks of
>>> memory for each node (IIRC one for key, one for data, one for the three
>>> pointers), so that lookups (which added unknown nodes to the tree)
>>> bottle-
>>> necked on the malloc() process with three calls per node added. We
>>> needed something like 7,000 lookups/sec but couldn't break 800.
>>>
>>> So I rewrote the btree functions to use only one struct per node, which
>>> gave an immediate speedup to better than 1500 lookups/sec.
>>>
>>> More checks showed that now the sbrk() function that malloc() called
>>> each time it needed to extend process heap memory had the same problem.
>>> So, I changed my code to use malloc() to grab MB-sized chunks of heap
>>> space and and wrote an application level function that allocated btree
>>> nodes in my chunk of heap and asked for more when it was needed. This
>>> gave me 25,000 looks/sec: job done!
>>
>> Isn't that what __mingrow was supposed to do in a more transparent way?
>>
> 'locate' doesn't find __mingrow (or mingrow) in my development
> environment. The pnly references I can find are in relation to a C#
> priority queue: this all happened long before C# existed.

http://www3.physnet.uni-hamburg.de/physnet/Tru64-Unix/HTML/MAN/MAN3/0892____.HTM

Arne

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web