Slashdot Mirror

But the Java fanatics just put in more and more features, regardless of whether sane languages had them or not.

Obvious?

Well, given the abstraction from actual hardware that is Java's goal, how would you create a way to pass data from machine to machine without worrying about things like word size and endianness?

Are you for real? Maybe I'm not getting your sarcasm, but this is a solved problem and was a solved problem back in 1997.

See here for one example of object serialization of binary fields that was doable back in 1997. Serializing 15 or so fields in a single statement; not exactly what I would call rocket science.

I used to think the same way, I really did. I even turned off JS in the browser. However I've changed my mind.

There are some legitimate reasons for javascript. For example, see this JS usage (with an explanation over here).

I'm sure there are plenty more like that, where a little bit of script can provide good value to the visitor.

I used to think the same way, I really did. I even turned off JS in the browser. However I've changed my mind.

There are some legitimate reasons for javascript. For example, see this JS usage (with an explanation over here).

I'm sure there are plenty more like that, where a little bit of script can provide good value to the visitor.

There is no logical difference between execution and murder versus imprisonment and kidnapping.

Except that one of them is irreversible.

You think imprisonment is reversible?
Anyway, regardless of one's stance, everyone should really read this before forming their opinion on death sentences...

I found, after decades of experimentation, that simplicity and consistency beats everything else if you want to produce reliable software. Now, I use C exclusively just so I don't have to deal with multiple different ways to do something because the C++ standards committee got a bee in its bonnet about the latest hot new concept that first came out in 1959 and was forgotten until last year.

The problem with possessing multiple ways to solve a problem is that every developer takes it as a personal challenge to find and use all the different ways. To make things easier I simply wrote a library containing those things that I usually need (sane string operations, c/line parsing, vectors, etc) and found that 90% of what you can do with X lines of fairly complex grammar in C++ can be done with around 1.5X of straightforward C grammer. I don't need the remaining 10% if it needs 300% cognitive effort to get.

The library is here: Extended C library, libxc, so help yourself (BSD license)

.

Documentation is over here: PDF link, but html available, although the documentation on the website is out of date. If you download the library source you get the full up-to-date docs.

Regression to the mean is, by definitive, a regression model that is applied to a set of data which fails to disprove the null hypothesis of "no correlation".

No. You're incorrect - from this link:

"In statistics, regression toward (or to) the mean is the phenomenon that if a variable is extreme on its first measurement, it will tend to be closer to the average on its second measurement—and, paradoxically, if it is extreme on its second measurement, it will tend to have been closer to the average on its first."

This definition is directly contradictory to what you thought the definition was.

You keep throwing out ad hominem attacks, but I have to wonder if you have even taken the standard freshmen and sophmore level math ciriculum for the sciences (statistics, linear algebra, discrete math, single and multivariate calculus, and differential equations) based on what you are writing.

It is not ad hominem to point out that you are making a mistake even HS students don't make. And your error of understanding is not just with "regression to the mean", it's with all the other linear algebra and statistics and logic mistakes you've made over the course of this thread. Be happy that I'm only pointing out one of them - I flat out ignored the incorrect logic statement you posted earlier. For a refresher logic course, you can see this - first semester notes. Note that this particular document was been online since around 2006 so you've had plenty of time to read it if the information was not available elsewhere.

Once again I must point out that stringing together random terms you found on wikipedia is no substitute for actually knowing the subject.

And yet the reality is exactly the opposite: Agile methods are by strong people, for strong people.

That wasn't my experience of agile... at all!? The most memorable one was when I was part of a dev-team on a postgrad course. Team leader insisted on agile, and then insisted that the (relatively tiny) project be done only when we're all together in the same room (we lived about 60km apart from each other in a rough triangle). He then insisted that we meet and work on the project (tiny one for postgrad module) two hours a day every day after work, with sixteen hours each weekend over a two month period and insisted that no telecommuting would be allowed. I left the team (and halted my MS temporarily); last I heard they actually did stick to the proposed schedule but failed the course anyway.

My other experiences with agile development (bear in mind that I approached this as I approached most new things: "Hey, Cool!") were mostly the same: the lack of even basic planning meant that work that was done was frequently reworked to the point of being unrecognisable as the original code; IOW, code was effectively thrown away, and not due to changing requirements but due to changes in the project that were forced due to a lack of a basic design.

It simply doesn't work with fuckups (be they drone or Rambo).

In my experience, most processes don't work well with fuckups.

But you are right, good devs figured out processes that work. And like any good dev, they refined them over time and with insight from others. Eventually distilling the process into a methodology...and they called it Agile.

I'm not so sure that that was the process that was followed: I wrote up the majority of this paper over here, and my take is that the smaller groups/companies are flexible enough to try new things. If they die trying then there are still numerous other smaller groups that will try something else. A few generations of this leaves behind only what works (AKA agile). Thus far this is in line with what you say above.

But this evolutionary action only works for small groups (see the references in the above link: one of them finds that agile performs as advertised only for tiny projects); large corporates and/or projects have to have the project designed upfront with at least enough detail to parcel out work to different subgroups. If they started developing without an overall architecture planned they'd mostly just be spinning wheels. For most human endeavors (whether building a house, bridge, automobile or even abstract things like 3D animated movies), a high-level vision is needed, and a high-level architecture. The details are filled in later. Why then do we believe that software, which encompasses the most complex things that humans have ever built, needs less design?

That's literally where all this came from: Great devs, using skill, experience, and creativity, to come up with the best ways to solve very common problem found in very similar situations. And then field testing and refining those solutions into a science.

I beg to disagree on this point: IT (and development) is not yet a science. There's a measurement for this that I forget (scales that measures how close a discipline is to being a science, that is), it was a long time ago that I did basic science reading (The stuff I've been doing the last seven years has not been basic).

The fact is projects, people, companies are much more typical then they are unique. They have the same types of people faced with the same types of problems. Only a bad dev would try and reinvent the wheel for each and every situation. A good dev reuses as much as they possibly can, be it tools, patterns, or processes.

-

We agree on this :)

And there are reasons th

No, it's not new or novel, but it's exactly what I proposed... you can already mix your own tags into HTML and style and process them.

Did something like this and was meaning to write up a blog post about this but never got around to it (hey, there's a weekend coming up :)

Feel free to read the rest of the directory for the actual implementation.

Android Sex-Selection Fertility Calendar [amazon.com]

Given that sex is down to whether the sperm carries an X or a Y chromosome, how does conceiving on a particular day affect the sex of the child? Ovulation is clearly periodical, sperm production not so.

Am I missing something?

Well, I have good reason for believing that each fertile day has a different probability for conception (if it occurrs at all) of a male/female foetus. My reasons and logic are well documented over here, and read section 3.2 of this document.

In short, XX and XY cells have different sizes, lifespans, motility and volume. These differences result in one living longer than the other, but moving faster.

Perhaps I could put together a team to trial this, but I have neither the funding nor the inclination to do so. I put this idea out there (along with a possible method for falsification) in the hope that someone who does have the time and inclination would do the study.

Thanks for the tip about smashwords.

No problem ;-) I've got books listed there so it pays to advertise the site :-)

Android Sex-Selection Fertility Calendar [amazon.com]

Given that sex is down to whether the sperm carries an X or a Y chromosome, how does conceiving on a particular day affect the sex of the child? Ovulation is clearly periodical, sperm production not so.

Am I missing something?

Well, I have good reason for believing that each fertile day has a different probability for conception (if it occurrs at all) of a male/female foetus. My reasons and logic are well documented over here, and read section 3.2 of this document.

In short, XX and XY cells have different sizes, lifespans, motility and volume. These differences result in one living longer than the other, but moving faster.

Perhaps I could put together a team to trial this, but I have neither the funding nor the inclination to do so. I put this idea out there (along with a possible method for falsification) in the hope that someone who does have the time and inclination would do the study.

Thanks for the tip about smashwords.

No problem ;-) I've got books listed there so it pays to advertise the site :-)

Google cannot hope to stay relevant if all it allows from the majority of devs are free apps on its market, and since most users don't care to load other markets, devs aren't going to bother with a platform that doesn't let them sell.

Wow! Are you kidding me?

I don't kid.

And don't call me Wow! ;-)

Google doesn't ALLOW devs. to get paid for their work?!?

Not unless you're part of a select group of countries. Link to my blog and spread the word. I'm seemingly the only android dev who isn't blinded by fanboyism to the point that I'd keep quiet about it. No one else is making this an issue, and until it becomes news, google aren't likely to fix the issue.
My Blog Takes A Stand (or something :-)). Searching the 'net shows that no one else apparently cares about this, which makes me think twice about which platform I should be targetting.

Frankly, if Apple weren't such douchebags themselves, I'd target their platform much more quickly. Apple won't even answer your questions until you pay them a $99 fee.

If only I could sell my app on google market

Sigh

hey're not going to replace traditional games, but there's room for both!

Of course there is - the combination of

• wide distribution,
• quick+easy development,
• ability to add advertisements and,
• very importantly, no requirement to download something that runs locally

is a sure-fire recipe for thousands of little games that you play for a few minutes before leaving it forever. Which isn't a problem for me - someone else will be along in a minute.

This shameless plug, for example, took me a full working day to write. Bear in mind that the last time I used javascript for anything other than menu mouse-overs was in 1999/2000. Fair enough, one feature still remains to be implemented (and I may even do that one day :-)), but if I attempted the same thing using some other platform (other than http/javascript), then:

• It would've taken more than a single day to develop
• I would not have the option of enabling/disabling ads easily
• The user would have to complete two steps in order to try (download, then play), instead of single-click-play
• Potential users may never find it in a google search. Now it's indexed properly, and via the ad placement, google knows about it.

Fair enough, I won't be able to write Far Cry at all in current browser platforms, but I wasn't going to devote a year of dev to a game, anyway

Depends on the app - see this for an app that does what it needs to, without actually losing anything over what a native app would give.

(Too lazy to implement splitting just yet - but as you can see the rest of it works just fine, and is platform agnostic, portable, etc)

over here - whats the odds that their data matches mine? :-)