|
|
Re: "No sliver bullet" is in the fine print
|
Posted: Dec 7, 2006 8:36 PM
|
|
> Firstly, I want to apologize for being a little less than
> civil in this thread. I think the technical term for this
> is being 'kind of a dick'.
>
<sarcasm>I, of course, was a perfect gentlemen. </sarcasm>
> I mean, you did piss me off a little but it's been a bad
> week and my mood tends to 'leak' into threads like this
> sometimes.
>
Join the club. It's called "caring about what you do". At least, that's what I tell myself. I don't think you can do this for a while without having a few closely held beliefs and prejudices. The challenge is to separate the two. It's hard.
> > It's very hard, if not impossible to do in the general
> > case for a general purpose language. Any useful
> features
> > need to be (or maybe more correctly should be)
> applicable
> > to a wide range of problems.
>
> I'm wondering if we may not be thinking about the same
> things here. I guess where I'm coming from is that I'm
> not against the high-capabilities of C++ (although I think
> some things could be disallowed but I'll address that
> later) but more that there are so many ways to accomplish
> the same thing. What I've been trying to say (badly) is
> that a language with the power of C++ but with a little
> spring-cleaning would be better. Maybe D fits this
> description. I'll try to get a chance to look at it.
>
I think that's D to a T.
> Here's an example of something I don't like in C++:
> pointer arithmetic. It's not allowed in Java and most
> t high-level languages. I'm sure there are cases where
> using it can optimize operations. But it seems to me that
> the compiler or runtime should be able to use this
> approach and much more safely.
C++ references are what most people should use in these cases. A lot of people don't, but we had that argument already. They aren't quite as abstracted as you like, but they make somethings that are easy to screw up with pointers much harder. In most cases the compiler compiles the two down to exactly the same code, so you don't lose anything by using references. I still find it amusing that Java has no pointers yet one of the most oft complained about exceptions is a NullPointerException.
> In Java 1.5, they
> introduced a for each type construct:
>
> for (int i : intArray) {
> // do something with i
> }
>
> It seems to me that the compiler or runtime can optimize
> this really well. Say it knows that the data will be
> contiguous. It can essentially use pointer arithmetic and
> potentially even drop the bounds checking (assuming the
> spec allows for this which I'm not sure it does.) In this
> way, we get our cake an eat it too. You get the raw speed
> without the pitfalls.
>
Sounds like STL iterators with a lot prettier syntax. I think the only reason STL iterators seem hard at all to people is the syntax is so God awful. I know it frightened me the first time I saw it. Perl, python, VB and just about every other language with associative arrays has this construct and has had it for a long time.
> Another example is not currently in Java but is described
> here:
> http://www.research.ibm.com/people/g/gupta/escape.ps
>
> With this runtime optimization, stack allocation, thread
> local allocation can be used, and synchronization dropped
> depending on the situation during execution. And this can
> be done with libraries which were written without knowing
> whether these optimizations would be OK. These are
> probably not new ideas but the are good ones all the
> same.
>
I just browsed it. I'll have to read that when I'm awake. I had a long day at work and went to my first Python User's Group meeting. I forgot how mentally draining it can be to spend 3 hours with some really smart people.
> > > > Ok. Abstractions leak all the time. Because of that
> I
> > > have
> > > > specific needs from time to time to get closer to
> the
> > > > metal than these abstractions allow. Taking that
> > > ability
> > > > away from me impairs my ability to solve problems.
> > >
> > > Perhaps. Perhaps you just haven't realized there is
> a
> > > much better approach. A lot of the times that I've
> > seen
> > > people drop down to the metal to solve issues, there
> was
> > a
> > > better (faster, less memory, more flexible) solution
> > > achieved by adding an abstraction.
> >
> > I don't disagree with that at all. Unfortunately 'A
> lot'
> > doesn't cover 'All'.
>
> Yes and I think that there needs to be a way to address
> those things. Python and Java both address this, although
> binding to native code in Java is a big pain (one of the
> bad things about Java.)
>
I tried binding to native code in java once. That was enough for me. It was almost a decade ago and it may be easier now, but with the amount of C# and VB I do, native code binding on windows is easy. I've worked for all Windows shops (I play with linux at home from time to time) and we've always used MS tools.
> > You're not a big fan of templates, so
> > you'll probably hate this, but here is an optimization
> > that I like a lot, not only because it also doesn't
> look
> > any nastier than regular ol' C++. You get brutally
> > efficient optimization that doesn't look any different
> > than the normal language syntax and this is better than
> > you can do in a lower level language like C to boot. So
> > maybe this supports your argument more than mine?
> > http://www.cantrip.org/emptyopt.html
>
> This seems like something that would be the job of a
> runtime or a compiler. There's some mention in that page
> of why the compiler can't in C++. In Java, I don't think
> the JIT can do that, but will unroll loops and I believe
> remove them if they are filled with no-ops, which is sort
> of a similar idea.
>
The compiler can't, but you can, stick it in a library and never have to write it again. If the compiler can do it, great. I'll take the help. To me this is just such a useful feature that I would rather deal with the cruft when I need this sort of power. I'm sure, at some point, something better will come along. I may be old and retired by then, however.
> > > > How so? I'll assume with your quick response you
> > didn't
> > > > get through the entire paper. Lisp was create
> > > specifically
> > > > as a notation to express functions, which is how we
> > > > express processes for a computer. Seems completely
> > > logical
> > > > to me.
> > >
> > > I'm fairly familiar with the idea of LISP. Just
> because
> > I
> > > think the idea was good doesn't mean I like that
> > > particular execution of it. You're not arguing that
> > this
> > > idea leads only LISP, are you?
> > >
> >
> > I'm not arguing that anything leads invariably to LISP.
> At
> > least, not its syntax, which what I'll assume you mean
> by
> > "that particular execution". But the ideas aren't new
> and
> > the languages that I hear people talk about (python and
> > ruby, mostly) that are going down the path you describe
> > credit at least some of their design to LISP.
> Invariably
> > overstates the case, but there sure is a high
> > correlation.
>
> I don't even know what we were arguing about. I think
> that the functional paradigm is a great idea but that LISP
> is that idea taken to an absurd conclusion. This is just
> my opinion, obviously. I don't think LISP's failure to
> become a dominate language is because this idea was a bad
> one, it's just that LISP seems strange and requires
> twisted reasoning for most developers. Languages that
> combine the functional and OO paradigms have the most
> promise, I think.
>
No doubt. This is one of the reasons I like C++. It has the ability to reasonably use most available paradigms in a reasonable manner. I think it is definitely the jack of all trades master of none language. Functional programming requries twisted thinking regardless. LISP just throws it right in your face. Plus, you still can't do anything like LISP macros in a language other than LISP. I've never had the need to use them, mind you, but that's the rumor.
> > > Give me an an example of the kind of thing you are
> > talking
> > > about that you do on a regular basis. Maybe you'll
> > > convince me.
> >
> > I used to help work on a database application that was
> > responsible at times for rolling up 10's to 100's of
> > gigabytes of financial data from leaf level data entry
> > nodes to summary levels for executives. Given the
> constant
> > changes to financial rules across the globe (the
> software
> > is sold worldwide), there are constant tweaks to the
> > rollup process. Given the large amounts of data that
> are
> > processed we need all the control we can get when
> running
> > this process. The object models and runtimes of more
> > modern languages bring this process to a grinding halt.
> In
> > order to handle this amount of data there are "tricks"
> all
> > over the place to conserve memory and shave CPU cycles.
> > For small consolidations that take seconds or minutes,
> > this isn't a big deal. Some of the tweaks, however,
> were
> > put in place to cut consolidations down from days to
> hours
> > or, in the best cases, minutes. Performance is a huge
> deal
> > for this app because nobody wants to start rolling up
> > their database Friday, leave for the weekend and have
> > maybe a 50/50 shot that it will be done when they come
> in
> > Monday morning.
> >
> > It has to run and it has to run in a reasonable amount
> of
> > time and given the need to properly apply the financial
> > rules (order of calculations matter, relationships of
> > certain members in the database change the calculations
> > depending on financial rules covering partially and
> wholly
> > owned subsidiaries based on country, etc.) you don't
> have
> > a lot of wiggle room with the algorithms. You have some
> > but not much because the numbers have to be right. The
> > only practical alternative is to make the computations
> > take less time.
>
> OK this is a good example. This may not have applied at
> the time you were working on this, but could parallel
> processing helped here or is the process necessarily
> sequential? It's ball is just getting rolling on this,
> but with the 16 core chips that are coming, this is going
> to become more and more important and easier to take
> advantage of. You still have to plan it out in Java, but
> it's definitely easier than I remember threads being in
> C++ and from what I've read lately (in this thread?)
> that's still the case. Using good high-level Object
> abstractions make retrofitting for threading a lot easier
> too.
This isn't my problem anymore :-) For the past few years they've taken the scale out instead of up approach for horrendous databases. Customers will buy 3 or 4 servers and run their rollups in smaller chunks in parallel. I can't imagine what hell a total rewrite of that app would be and it would have to be a total rewrite. If you think C++ is a frankenstein, I hope you never, ever see code like this stuff.
Threading in C++ still isn't great (all platform dependent) and the committee is trying to address this for the next version. This is worth a read if you care to spend a few minutes on it http://www.artima.com/cppsource/threads_meeting.html. I think I had to read it 3 times before digesting it all. Concurrency is hard :-( In the general case I think good threading libraries are going to gravitate toward Erlang. Erlang makes several assumptions that makes threading much easier to abstract and just about everybody I know that has ever looked at Erlang and done concurrent programming in it has been reasonably happy, which is quite a statement when talking about concurrent programming. I've never been happy doing that stuff.
|
|
Previous Topic
