C++ Community News Forum - The Problem with Programming

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

C++ Community News Forum
The Problem with Programming

212 replies on 15 pages. Most recent reply: Dec 8, 2006 6:12 AM by James Watson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 212 replies on 15 pages [ « | 1 ... 9 10 11 12 13 14 15 | » ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming

Posted: Dec 1, 2006 2:38 PM

> > There's an unmentioned disconnect here. You and I are
> > saying 'a little' more memory is needed. But they are
> > saying that extra memory needed is very significant.
> > There are two feasible explanations: We have different
> > t ideas about what a 'little' memory is or we disagree
> > fundamentally about the memory usage of Java.
>
> > I think it's the latter because a MB or two is not
> going
> > to matter on any reasonably modern server or desktop
> > hardware.
>
> James, for processes that are spun up in quantity and that
> are short-lived, Java's footprint (CPU and memory) as
> implemented by the JIT and Hotspot style JVMs is
> unacceptable. That is an area that "compiled" languages
> (in the traditional "emitting and linking of native code"
> meaning) have a huge, obvious and understandable
> advantage.

I wasn't really arguing this and I have never argued that Java can be thought of as a replacement for C++. But I will point out that it's not quite as bad as people make it out to be. I have a custom regex tool that I run from the command line and often pipe to itself many times in conjunction with standard unix utils. The footprint is under 7K and when there isn't much work, it executes, prints several screens of text and exits in the blink of an eye. Literally, sometimes my windows task manager doesn't even catch it. Maybe that's large by some standards but it's not the 64M footprint monstrosity that people make it out to be.

> Java is particularly good at long-running (say a minimum
> of 10 seconds and a maximum of 10 months) processes. At
> less than 10 seconds, a good chunk of the work is spent in
> the JVM implementation itself spinning up, and in very
> long-running applications, Java is still not so completely
> stable that I would trust a single JVM to run forever.
> (That's obviously one of the reasons why we keep managing
> to sell Java clustering software.)
>
> There is no one-size-fits-all, but (IMHO) Java covers the
> middle 98% better than the other options that I have
> experience with. C/C++ coincidentally is pretty good at
> both ends (software that needs to run until the machine is
> shut off, and software that needs to start up, run and go
> away within a fraction of a second).

But as you mentioned before, many (if not most) JVMs are written in C++. If the C++ is great for things that must stay up forever, then shouldn't we expect the JVM to stay up forever?

I know that's an unfair question and you shouldn't answer it. The point is that the developers are the key. The only thing that I ever meant to say about C++ in this thread is that it's not developer friendly. Powerful, yes, very much so. I don't think Java is better than C++. In fact I've got a lot of complaints about Java. But it very much simplifies things, especially on large teams. Because there is very little redundant syntax and the code is so transparent (although verbose at times), I don't spend a lot of time scratching my head trying to figure out what line of code does. I spend a lot of time scratching my head at the stupid approaches that are used but that's a different rant.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming

Posted: Dec 1, 2006 2:48 PM

> In the case that I was working
> with, I could "retrieve" a half million rows of data (from
> a hard-coded test driver) and realize a virtual "set" of
> data in memory to manage those retrieved results, and I
> could do that in a very few MB of memory (i.e. for the
> structures themselves). In Java, the same would be no less
> than 8MB, since each "row" would have to be a separately
> allocated object, and if that internally had any object
> state, it would be at least 16MB or 24MB (one or two
> objects respectively). So when you are dealing with large
> "arrays of structs", or things that benefit from explicit
> stack allocation, then Java is much less efficient (both
> space and time) than C++, and yes that will directly
> contribute to GC cycles being burnt (500,000 actual
> objects to manage instead of a hand-full of pointers
> representing block-allocated regions to hold 500,000 row
> structures).

Could you not take the same approach in Java and put all the data into one (or a reasonable number of) byte array with one 'window' object that you moved along the array as if it were a pointer? I'm working now making data described in COBOL copybooks usable in Java programs. I could defer Object creation until the item at a certain spot in the file is requested. But there's no point. It's waste of time.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: The Problem with Programming

Posted: Dec 1, 2006 4:42 PM

> Could you not take the same approach in Java and put all
> the data into one (or a reasonable number of) byte array
> with one 'window' object that you moved along the array as
> if it were a pointer? I'm working now making data
> described in COBOL copybooks usable in Java programs. I
> could defer Object creation until the item at a certain
> spot in the file is requested. But there's no point.
> It's waste of time.

Technically, it can be done in that manner -- it is always possible to represent any data structure as a byte array ;-).

However, it is completely un-natural (and its constituent parts thus useless, since they are not objects) in Java.

The equivalent in C++ would be to only use strings, and store all data structures (particularly pointers <BWEG>) as strings. Yes, you can do it, but any decent C++ programmer will want to shower just having considered the notion.

Peace,

Cameron Purdy
http://www.tangosol.com/

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

"No sliver bullet" is in the fine print

Posted: Dec 1, 2006 9:44 PM

>I would dare say that I am the first to say that there is no such thing as a silver bullet.

Saying "We never claimed that it was a silver bullet" is software development's version of the "results not typical" disclaimer diet plans use after a testimonial by a newly-thin devotee.

If a diet plan can't make the average dieter shed pounds more easily or a software language or methodology can't lead the typical developer to create much better software, then there's really no compelling reason to adopt it.

My attitude is: wake me when you have a silver bullet, I already have many varieties of wolf's bane to choose from.

Amanjit Gill

Posts: 3
Nickname: agill
Registered: Dec, 2003

Re: The Problem with Programming

Posted: Dec 2, 2006 11:05 AM

> Now if only C++ had garbage collection...

- Actually you can use Boehms garbage collector right now if you want to.
- I personally found using smart pointers a revelation - you never call delete on things, you still need to plan things (circular refrerences)... just think about boost shared::ptr or its incarnation as in the C++ TR1 report

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: The Problem with Programming

Posted: Dec 2, 2006 12:09 PM

> I'm more
> interested in what you think where things are going and
> how Smalltalk fits into that.

Fine. I think the last 25 years of development have been a long circuitous path towards Smalltalk. We had Smalltalk, and the hardware couldn't quite handle it. So we got the Mac which borrowed the GUI and some of the component architecture (code resources). We got OO Pascal - a rough approximation. C++, a similar rough approximation. Objective C is about the best approximation in a complied language and was what C++ probably should have become. It even borrowed Smalltalk's syntax.

We got Java, borrows C++'s syntax, rotten type system, and doesn't fully embrace objects so it cheats with primitives and pretend class objects, but Smalltalk's virtual machine, portable graphics, garbage collection, and some really pale imitations of reflection.

Ruby, borrows liberally from Perl's integration with unix, and Smalltalk adding closures, dynamic typing, similar message syntax, etc. Yet none of them have successfully yet embraced the Smalltalk image and environment.

Meanwhile, everybody seems to have recently discovered the power of languages that can implement themselves and we have PyPy, there is something similar for Java I think. Meanwhile, Avi Bryant and Charles Nutter are swapping emails about implementing Ruby in Squeak - which would be a big performance boost for Ruby and bring Smalltalk into ever greater awareness as it becomes a faster Ruby interpreter than the one most people use now.

Now I see the Pepsi project as the first thing that may both absorb and go beyond Smalltalk.

> So you think that Smalltalk is going to make a comeback?

It is making a comeback. Conferences are getting bigger, more users are coming by to various events, I and a number of others who kept the faith through the Java nuclear winter are now making their livings with it again. JCP member and recent Sun employee Gilad Bracha has been spotted looking for Squeak talent.

> Or is this Smalltalk living vicariously through Ruby?

That has helped push things in the right direction. But Ruby lacks the whole package gestalt of Smalltalk. I'm seeing a lot of Ruby fans coming over. I don't see people going the other way. Of course, I'm not looking for them :-)

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: The Problem with Programming

Posted: Dec 2, 2006 2:58 PM

> Fine. I think the last 25 years of development have been
> a long circuitous path towards Smalltalk. We had
> Smalltalk, and the hardware couldn't quite handle it. So
> we got the Mac which borrowed the GUI and some of the
> component architecture (code resources).

Your history is not quite correct. It was initally the Lisa that borrowed ideas from Xerox and the GUI was really an Alto innovation, not exclusively a Smalltalk one. There were many Alto programs that had nothing to do with Smalltalk ( Bravo, Laurel etc).

In addition, C++ isn't any kind of rough approximation of Smalltalk; like Smalltalk itself, it borrows concepts directly from Simula.

I have nothing against Smalltalk, but it doesn't play the key role in the history of computing you suggest it does.

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: The Problem with Programming

Posted: Dec 2, 2006 7:17 PM

> > I'm more
> > interested in what you think where things are going and
> > how Smalltalk fits into that.
>
> Fine. I think the last 25 years of development have been
> a long circuitous path towards Smalltalk.

Handwaving gets you nowhere. Yes, new languages don't usually appear in from a vacuum.

> We had
> Smalltalk, and the hardware couldn't quite handle it.

We had many languages that the hardware couldn't quite handle. Hell, just 15 years ago you had a substantial amount of PC software written in assembly.

> So
> we got the Mac which borrowed the GUI and some of the
> component architecture (code resources).

Xerox Parc? Languages aren't GUIs.

> We got OO Pascal
> - a rough approximation. C++, a similar rough
> approximation.

Oh boy, C++ borrowed the class keyword and now it's a "rought approximation". You need to check the reality.

Objective C is about the best
> approximation in a complied language and was what C++
> probably should have become.

Who says? Smalltalkers?

>
> We got Java, borrows C++'s syntax, rotten type system, and
> doesn't fully embrace objects so it cheats with primitives
> and pretend class objects

C# is fully OO by that definition, but are people still buying into the snake oil of "OO is the holy grail"?

, but Smalltalk's virtual
> machine, portable graphics, garbage collection, and some
> really pale imitations of reflection.
>

And logic doesn't dictate that because we stand on the shoulders of giants that we reverse time.

> Ruby, borrows liberally from Perl's integration with unix,
> and Smalltalk adding closures, dynamic typing, similar
> message syntax, etc. Yet none of them have successfully
> yet embraced the Smalltalk image and environment.

Since you're in love with proxying off to bloggers, you might want to check out James Robertson's (Cincom) podcast about the problems with smalltalk image-based environments.

>
> Meanwhile, everybody seems to have recently discovered the
> power of languages that can implement themselves and we
> have PyPy,

Oh yes, EVERYBODY has in your blinders world

there is something similar for Java I think.
> Meanwhile, Avi Bryant and Charles Nutter are swapping
> g emails about implementing Ruby in Squeak - which would
> be a big performance boost for Ruby and bring Smalltalk
> into ever greater awareness as it becomes a faster Ruby
> interpreter than the one most people use now.
>

Great, now can we extend Smalltalk past 1980. Hint, look at Slate.

> Now I see the Pepsi project as the first thing that may
> both absorb and go beyond Smalltalk.
>

Never heard of it, but I'll take a look. Once again, take a look at Slate.

> > So you think that Smalltalk is going to make a
> comeback?
>
> It is making a comeback. Conferences are getting bigger,
> more users are coming by to various events, I and a number
> of others who kept the faith

Yeah, the "faith". that's your probem.

> through the Java nuclear
> winter

Just stop the insanse fanboyism

>are now making their livings with it again.

Smalltalk never died McFly

> JCP
> member and recent Sun employee Gilad Bracha has been
> spotted looking for Squeak talent.
>

Oh boy, better tell James Robertson.

> > Or is this Smalltalk living vicariously through Ruby?
>
> That has helped push things in the right direction.

Just stop the handwaving about "right directions". It would be nice for somewhat objective analysis that doesn't involve fanboysism

But
> Ruby lacks the whole package gestalt of Smalltalk. I'm
> seeing a lot of Ruby fans coming over. I don't see people
> going the other way. Of course, I'm not looking for them
> :-)

"you're not looking for them". See, that sums up your whole problem. You're wrapped up in fanboy world and incapable of objective analysis.

The IT world is not going towards dynamic typing, because we already know that there is no reason to. Look at all the language research that is going on. Is the Smalltalk style of programming being researched? uhh, nope.

We're past that. We know the benefits and pitfalls of an OO-all world. Time for you to wake up and see where things are really going. We can take bits and pieces of Smalltalk (mostly the kick-ass Environments), but let's not get silly and say that Smalltalk is on the rebound.```

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: The Problem with Programming

Posted: Dec 2, 2006 9:09 PM

> > > I'm more
> > > interested in what you think where things are going
> and
> > > how Smalltalk fits into that.
> >
> > Fine. I think the last 25 years of development have
> been
> > a long circuitous path towards Smalltalk.
>
> Handwaving gets you nowhere. Yes, new languages don't
> usually appear in from a vacuum.

You asked what I think. What handwaving? I have to prove what I think?

Anyhow, I can't tell what your position is based on your screed. You seem to keep changing positions while making ad hominem attacks. Although you seem to be a big fan of Slate. I'll tell Brian when I see him. He's working for me just now doing - oh holy cow - Smalltalk programming.

Scott Bockelman

Posts: 7
Nickname: mafjgbs
Registered: Feb, 2003

Re: The Problem with Programming

Posted: Dec 3, 2006 3:57 PM

> If buildings or ships was constructed with average quality
> in software, the contractors would have been sued and
> unemployed pretty quick. Why is this so different in the
> Software industry? Why does not (most) stakeholders care
> about quality?

Why is it we always assume that making software is like building buildings and furthermore, why do we assume that building design and construction does not also suffer from all of the same pressures and resulting trade-offs in terms of "quality"? (I suspect it does.)

Software is nothing like physical architecture, which is (more) constrained by the "real-world" laws of gravity, weather, etc. Software lives in a purely hypothetical world of its own design (except the stuff that actually interacts with the real-world of circuits and electricty and the UI which has to interact with the real world of human interactions).

Also, with software, you can reuse a quality component repeatedly; in construction, you must build a new one every time; you would expect software therefore to get better faster and faster better.

Humans have been making "modern" software for only about 50 years; humans have been building buildings of some nature for thousands -- give us a break... we are still learning. We are constantly finding new things with which to be concerned (did anyone really think to code against a denial of service attack before 1997?) and to which to apply technology.

Finally, quality is a completely subjective ideal anyway...for many uses, even the most "poorly written" (whatever that means) piece of software will serve its purpose.

What I find interesting is that many of the respodents attack one language or another, rather than entering into the broader topic here. It is this focus on the means that continues to detract from the ends. When I hire a carpenter, I really don't care what kind of hammer he uses (in fact, he probably uses a nail-gun these days), but I do care about what his idea of quality constrcution is and whether it is compatible with mine. (And how much he is going to charge, of course!)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: "No sliver bullet" is in the fine print

Posted: Dec 3, 2006 7:20 PM

> >I would dare say that I am the first to say that there is
> no such thing as a silver bullet.
>
> Saying "We never claimed that it was a silver bullet" is
> software development's version of the "results not
> typical" disclaimer diet plans use after a testimonial by
> a newly-thin devotee.

That seems to me a lot like this:

http://en.wikipedia.org/wiki/Perfect_solution_fallacy

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Problem with Programming

Posted: Dec 3, 2006 7:22 PM

> Technically, it can be done in that manner -- it is always
> possible to represent any data structure as a byte array
> ;-).
>
> However, it is completely un-natural (and its constituent
> parts thus useless, since they are not objects) in Java.

I don't know that it's entirely unnatural. We often read data as byte streams in Java. Delaying Object construction isn't a bad solution, it's just usually not worth the effort.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: The Problem with Programming

Posted: Dec 3, 2006 7:22 PM

> What I find interesting is that many of the respodents
> attack one language or another, rather than entering into
> the broader topic here.

To make things more interesting, the choice of the programming language affects not only the quality but also the productivity of work much less then most people assume. Having (seriously) worked with 6-7 different programming languages in my career, I can't say I was more productive when using language A vs language B. Of course, I never used silly combinations like C++ for a web portal or Perl for a threading library, but as long as one uses a language for what it was designed in the first place, I just don't think it has much effect on the project outcome. People make the difference, not programming languages. I'll rather take good developers and work with NASM and Notepad than bad ones with ... (insert your productivity tool of choice - don't want to start another flame war :) )

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: "No sliver bullet" is in the fine print

Posted: Dec 3, 2006 9:19 PM

> > >I would dare say that I am the first to say that there
> That seems to me a lot like this:
>
> http://en.wikipedia.org/wiki/Perfect_solution_fallacy

It may seem that way to you but you're wrong. I'm not rejecting anything on the basis that it isn't perfect. I'm suggesting that there are already many worthy choices and adopting something new doesn't make sense unless there are very significant advantages.

New languages and methodologies are often promoted as if they were silver bullets and then when somebody proves they don't live up to their claims, the proponents fall back to the "no silver bullet" variety of CYA.

When in the last 15 years has a new language been first introduced truthfully with words like: "It's no silver bullet, it won't significantly improve your software, but it does offer a few innovations and it's a nice little language."

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Problem with Programming

Posted: Dec 4, 2006 6:01 AM

> > Now if only C++ had garbage collection...
>
> - Actually you can use Boehms garbage collector right now
> if you want to.
> - I personally found using smart pointers a revelation -
> you never call delete on things, you still need to plan
> things (circular refrerences)... just think about boost
> shared::ptr or its incarnation as in the C++ TR1 report

There are some potential problems:

1) Boehm's GC is slower than GC can be because it does not take into account type information. For example, if I have an object with 1 pointer and 4K of numbers, the whole object will be scanned for pointers. Same goes for the stack as well.

2) circular references is a big problem. In the software that I am writing, having two things linked together via a circular reference is the norm.

It is not always clear when you design classes where the circular reference might come from. For example, in one project, I had no circular references in my object model until some class was required to have a pointer to another class, which introduced a circular reference through inheritance: a subclass somewhere had a pointer to another class which directed the graph to the newly introduced class, thus making the app leak memory...it was a very nasty bug to catch, and in order to solve it, a whole stack of classes needed re-engineering, in order to convert some pointers to weak ones.

All these issues make writing software with C++ more difficult than it ought to be.

Flat View: This topic has 212 replies on 15 pages [ « | 9 10 11 12 13 14 15 | » ]

Previous Topic

Next Topic