Slashdot Mirror

Maybe in the future computers or compilers will be smarter and faster such that if we want to represent "1/3", it will actually store it as a ratio or formula *internally* instead of floating point. I may only turn to floating point if the equation complexity exceeds a certain threshold. But this is merely a thought experiment for the future.

The current way we do it might still be obsolete fairly soon for other reasons. With cheaper memory and CPU we have more practical options now. For more on this, see:

http://www.c2.com/cgi/wiki?NumberTypes
   

I'm pretty sure you can remove the word "impure" from the GP and the statement will still hold. You can see a discussion here.

Educational software switching from a language with a bias towards systems programming to a language for the average programmer: that's good data from which to extrapolate.

TestDrivenDevelopment on the original wiki (Ward Cunningham's). And a lot of the stuff it links to, and so on....

Another good one would be the Python Cookbook on ASPN. And at a more abstract level, Ward's Wiki has explanations and discussions of a wide range of interesting tools, languages, and techniques.

This page has a list: http://c2.com/cgi/wiki?PythonIde (including some mentioned above).

It also mentions http://www.die-offenbachs.de/eric/index.html which is Free (speech and beer).

Personally, I use Gedit (though I know it's not cross platform). But there's a question. Why do you have to use the same editor on each platform? Are you moving around often enough that it becomes an issue?

I'm flattered by your comments, but I'm afraid I'm not even remotely qualified to present at a conference, particularly not one on Agile ideas. I wish you luck, though. It's a bit far from the UK to come for a visit, so have a beer for me while you're there. :-)

I understand, but you should definitely think about it.

Almost all of the presenters are people working in the field; few are full-time "experts". And by definition, the "Questioning Agile" is meant to draw in outside views. If you're already mentoring junior developers and can present to 20-30 people, then I'm sure you're as qualified as the average presenter. The rest is preparation, and the year until Agile 2009 gives you plenty of time to develop your thesis, to collect evidence of the problem, and to deliver a couple of practice talks to local user groups or other interested parties.

Don't forget there are also a variety of European Agile get-togethers, from the London Extreme Tuesday Club to the large annual conference. You can keep an eye out for ones in your area on the Agile Alliance events page.

But I'm serious that we're always looking for outside views. the Agile 2008 closing keynote is by Alan Cooper, who for years publicly maintained that we were all dangerous lunatics, inimical to good software development everywhere. He's now moderated his position a little, but I know he's coming to challenge a variety of our notions, and I'm looking forward to it.

And yes, I'll definitely hoist a beer in your lack of name. :-)

I'll always admire T.S. Elliot for saying, "I'd have written you a shorter letter, but I didn't have time."

This is the first time that I have seen this quote attributed to T. S. Elliot. Usually I see it attributed to Mark Twain, who did in fact use it. However, it comes from before him. It has been attributed to Samuel Johnson as well, but it is not his either. Instead, it comes from Blaise Pascal's "Lettres Provinciales", Letter XVI in 1657:

Mes Reverends Peres, mes lettres n'avaient pas accoutume de se suivre de si pres, ni d'etre si etendues. Le peu de temps que j'ai eu a ete cause de l'un et de l'autre. Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte.

http://fr.wikisource.org/wiki/Les_Provinciales_-_Seizi%C3%A8me_lettre_aux_r%C3%A9v%C3%A9rends_p%C3%A8res_j%C3%A9suites

My Reverend Fathers, my letters are not accustomed to follow so closely, nor to be so extensive. The limited time that I had was because of one thing and another. I made it longer because I have not had the opportunity to make it shorter.

Please forgive my poor translation.

http://www.samueljohnson.com/apocryph.html

http://www.37signals.com/svn/posts/454-why-most-copywriting-on-the-web-sucks

http://c2.com/cgi/wiki?TimeToMakeItShort

http://lists.village.virginia.edu/lists_archive/Humanist/v05/0444.html

I find that while natural keyboards can be useful for extended periods of typing natural languages (i.e. writing papers at university) they are not optimal for the type of work that is more typical in engineering fields, such as programming or CAD, where there are sporadic bursts of typing combined with mousing, stopping to think some bit of code through, or switching windows to run a few google queries on the problem(s). There are some engineers who go out of their way to learn a really different input device (ala the data hand for example), but most of my programing friends and I prefer the straight up standard keyboard.

"The great advantage I find with the level of restriction that Java puts on your types is that it enables brilliant development tools."

Brilliant development tools for dynamic languages were around long before Java appeared. LISP machines and Smalltalk's browsers and the old PARTS visual component wiring environment come to mind here. These notably sophisticated development environments ran in significantly less memory than a modern CPU has in its internal cache on processors clocking at a few MHz.

"I can say from experience that refactoring of an app written in a dynamic language can be a colossal pain in the ass. Just finding everywhere that a particular class is being used can take hours or days."

I suggest therefore that you explain how people managed to write first refactoring tool (the Refactoring Browser) in and for for Smalltalk, a dynamically typed language.

http://c2.com/cgi/wiki?HistoryOfRefactoring

Forth, an interactive non-typed language, has also used the term "factoring" to refer to what's now called refactoring since the early 1980s. It's something LISP programmers have also been doing since at least the 1960s, although the nature of LISP meant that no special tools were required.

http://c2.com/cgi/wiki?OtherLanguagesForTheJavaVm That page gos in to it a bit more. C is nearly ASM so it's very hard to turn it into a language like Java that is so automatic. I'm sure it can be done but the people who like C see no reason to use something as wasteful as Java and the people who like a Java see no need for this kind of difficult project. "Why translate the C to Java Byte Code when we can just rewrite it in nice portable Java?".

In the end I don't think it is a bigger job then Android just one that has lacked demand until now. As it is I get the feeling that once Android is here a lot of people who were angry that they can't run their favorite C programs on their phone will find reasonable Java equivalents that they did not know existed. I would expect that any that do not exist will be written just for Android. The world has a ton of Java programmers right now.

Make it work. Make it Right. Make it Fast. In That order!

Architecture first, design next, get it doing what it is supposed to do. Optimise for speed. Maybe iterate over the design if a new algorithm is needed. And yeah there are sure to be exceptions. There is no algorithm for correct software implementation.

Premature Optimization is the root of all evil.

I've never seen anything saying otherwise.

Follow any of these sets of rules:

http://c2.com/cgi/wiki?RulesOfOptimization
http://schwern.org/~schwern/talks/What_Works/What_Works/slide016.html
http://www.cs.cmu.edu/~jch/java/rules.html

Or my version--
1) Don't optimize, no really, don't.
2) If you absolutely have to, write it unoptimized, test it, write it optimized, then:
2a) If the first is anywhere in the ballpark, throw away the second,
2b) If the second has enough of a proven, documented speed gain to get you past some accept/no accept barrier, comment out the slower one, but keep it so the next guy can follow the "Good" code.

If you don't document exactly what you did in the code and why, I'm going to refactor it into something readable the second I see it.

Also--know how to program. Choosing a linked list instead of an array list for an insertion sort is just programming correctly. It's not an optimization.

-1 offtopic... Just wanted to help the parent out with his cow-orker.

without this reference.

http://c2.com/cgi/wiki?BasicConsideredHarmful

I wish I could find the original document.

They're the original Wiki as far as most of us are concerned.

I hate to be a pedant (too late), but I'm pretty sure the original wiki was the Portland Pattern Repository's Wiki. Really a neat site if you haven't seen it, and should be very enlightening to any software monkey out there. Not trying to be pedantic (really!), just hoping to be informative.

We're in a thread about that Wikipedia.

Point. I'll shut up now :)

They're the original Wiki as far as most of us are concerned. The fact that there's a million things calling themselves Wiki-whatever. We're in a thread about that Wikipedia.

From what I learned, Ward Cunningham created the original wiki. You can wallow in ignorance, or you can learn new things. I know people will use "Wiki" as slang for Wikipedia the same way they use "Dave" as slang for "The Dave Matthews Band" (which particularly bothers me, since it implies the rest of the band that's not named Dave is insignificant)... but that doesn't mean I won't correct people. It's not pedantry, it's knowledge.

I think it's fairly common in the XP community, e.g. at Portland Pattern Repository's Wiki, so it's got a certain pedigree :-)

Oh, and here's a link to a simulation written by others:

http://c2.com/cgi/wiki?MontyHallSimulation

See "TRIPS architecture" on the wiki

See "TRIPS architecture" on the wiki

Don't forget the feeling of smug self-satisfaction.

On Slashdot? No worry that will get forgotten. Here we all worship at the church of Laziness, Impatience, and Hubris.

It's a wiki for people who want to take control of the job. It's mostly about extreme programming, but much of it can really be applied to any process system.

If that's not a strongly typed language then I don't know what is.

That's manifest typing.

My favorite definition of "strong typing" comes from Shriram Krishnamurthi's Programming Languages: Application and Interpretation (p. 205):

So what is "strong typing"? As best as we can tell, this is a meaningless phrase, and people often use it in a nonsensical fashion.

Benjamin Pierce (author of Types and Programming Languages) wrote something similar (see Mark Jason Dominus quoting Pierce on "____ typing"):

... the usage of these terms is so various as to render them almost useless.

The government can force you to pay damages if the shareholders successfully sue you for failing to turn a profit due to failing to accommodate 80 percent of your market.

I think the underlying part of this thread is a Layne's Law dispute over the definition of "to force".

Use them to build a massively parallel sequential search engine:

http://www.c2.com/cgi/wiki?CheapMassivelyParallelSequentialSearch

I think to be a decent engineer you should know at least one tool/language in each relavent category. It may or may not be the same one you end up using but at least you will know the basic concepts.

C++ fills the niche of where you still want tight control but some OOP capabilities would be usefull.

"The difference between theory and practice is greater in practice than in theory"
my variation on http://c2.com/cgi/wiki?DifferenceBetweenTheoryAndPractice
Which is, BTW, the original wiki.

Forth Assisted Hand Assembly. It's not quite naked but it is pretty revealing. :-P

my current major language (Igor pro) will use all the cores automatically, and how many languages do multithread this way? Matlab(?), Octave(?)

LabVIEW, by its very nature [which is graphical - based on "G" - the "Graphical" programming language] is kinda/sorta topologically self-threading: If a piece of LabVIEW code sits off in its own connected component, then [more or less] it gets its own thread.

Of course, all your ".h" & ".c" [or ".cc"] files [& their innards] might very well break down into little distinct connected components which are ripe for running their own threads, it's just that you can't - unless you're some sort of a super genius - you can't readily visualize all those connected components as they exist in your code.

Now you and your colleagues could try to anticipate the connected components a priori, during the "planning" phase: You could draw huge pictures on the dry-erase board, and everyone could yell and scream at each other about the topological structure which the code should ultimately embody, and then everyone would have to promise - Scout's Honor! - that they would stick to the blueprint [which they might very well resent as having been shoved down their throats by some pointed-headed suit who didn't have any clue what he was talking about] - but the beauty of LabVIEW is that THE CODE IS THE BLUEPRINT [which I think is a point that Jack Reeves used to make].

There's actually a Slashdotter, MOBE2001, who maintains a blog called Rebel Science News, who's got some pretty interesting ideas here - he seems to be leaning towards a graphical approach to this [realizing that the fundamental nature of the problem tends to be topological, rather than anything which we (YET!) would recognize as semantic], but his program is very, very ambitious [if I had a couple of spare lifetimes, I must just throw one in that general direction].

Another line of thought which everyone should keep an eye on is the discipline of Petri nets - it's kinduva big graphical/topological approach to state machines, which [if someone were to put the necessary elbow grease into it] might prove to be very useful in squeezing the most bang for the buck out of these massively-multicore CPU's.

We were kinda missing a fully-committed competitor for prestige and bragging rights, like we had when we were pushing to the Moon in competition w/ Russia. ... the only reason NASA appears to be getting back into the manned-mission-to-space thing again is because the Chinese got one of their own into space, and Russia+India want to put folks on the Moon... kinda sad that it takes ego just to get people working towards what should be a solid ideal in the first place

I agree. But there are other differences in play today, too. It makes it hard to see for sure how it plays out. For example, now that the fully-committed competitor turns out to be countries to whom the US outsources the lion's share of its work, what is the significance of a "competitive program" with those countries? Who will have the resulting bragging rights?

One perceives some sort of variant of Gerald Holton's remark about Giants is called for here. Something vaguely like: "In the modern world, our greatest achievement would be to pull the rug out from under the giants upon whose shoulders we have elected to stand."

My personal sense is that the space program was not a way to show off that we were technologically good, but rather was a path to becoming technologically good. That is, it was the investment in US infrastructure that mattered, and all the better that it was for a peaceful purpose and gave mankind hope that people could use technology for something other than weapons. The open question is not whether the passport carried by the person going to Mars is a U.S. one, but where the dollars spent on R&D will flow to. If a by-product of the program is not a ramping up of interest in and investment in US math and science programs, then the whole notion that we are competing is a sham. The space program was never about space.

And besides, if we want to go somewhere that has air that's hard to breathe and a temperature that isn't so good and not very much drinkable water, we can do that easier than building a spacecraft for just a couple of people: By sooner than 2031, with very little effort on our part, we can make the Earth itself into such a place and not even have to get off the couch to do it. We can just go on ignoring global environmental and climate issues and we'll be in "out o' space" in no time...

Separation of Church and State does not equal Sterilization of Church from State.

Honest Christians should always ...

Genesis 1:28 "God blessed them and said to them,... "fill the earth and subdue it."" If that isn't a command to perform scientific discovery, I don't know what else is.

Genesis 2:20 has an example of God facilitating Adam in naming all the creatures of the world; blatant scientific observation and categorization.

Cheap Massively Parallel Sequential Search:

http://www.c2.com/cgi/wiki?CheapMassivelyParallelSequentialSearch

I think Web 2.0 is a recognition that the Web, as a medium, is much richer than the mainstream originally thought. So, mostly it's investment hype -- VCs are putting money into the Web again.

From a qualitative perspective, it's all old news, but, as Gibson would say, "the future is already here, just not evenly distributed". A lot of the social & interactive aspects of the Web circa 1997 were pretty geeky. Today, they're common place.

So, I'd say Web 2.0 is:
- The web experience when most people have broadband. Web 1.0 was nicknamed the "world wide wait', if you'll recall.

- A recognition that the Web is actually an integration platform. In 1997, there was huge pressure to turn HTTP into CORBA. That was resisted by the W3C. The REST architectural style was ignored for many years during the development of so-called "Web Services", but it's re-emerging as a major factor in the web's success.

- The dynamic AJAX stuff that isn't proprietary to one browser

- The recognition that most people aren't consuming content from big content providers, ala TV. that's what people *thought* the web would/should become in Web 1.0. Turns out that it's a lot more participatory. Sure, there's lots of content that's created by pros, but also tremendous amounts of amateur content (youtube, myspace, facebook, etc.).

- Besides "participation", the big deal now seems to be that people understand "links". I recall in 1998, most content was all about "portals", where it was all big flashy media, but was all about keeping you on that site. You wouldn't see inline links in blocks of text, you would see buttons or big titles.

Easy linking is the big deal behind Wiki's and Wikipedia. More than any other feature, they made linking easy. You just had to SmooshWordsTogether on Ward's Wiki, instead of using an HTML anchor tag. That alone took a good 10+ years to trickle into the mainstream.

- You also see fewer people demanding Lynx-readable websites. :-)

Anyway, it's all old hat for a techie, but very new for the mainstream, and its mostly being noticed because of the new generation of high school and college kids that grew up with the web.

I've used PHP, Perl, Ruby and Python (in that order) and I can confirm that Python is in fact cleaner. One of the reasons being it's spartan syntax. It's one of the goals of the language. :)

PHP is just ugly, (see grandparent) Perl and Ruby are quite fun and share the same philosophy (see TIMTOWTDI) where Python is just the opposite (although fun too).

Python and Ruby also share their deep roots in clean object orientation, where Perl's OO syntax is - though bolted on - very flexible and even more TIMTOWTDI than Ruby's.

Just to set things straight, I really like Perl, Ruby and Python, though I can confirm that developing web applications with Django is bliss.

I've used PHP, Perl, Ruby and Python (in that order) and I can confirm that Python is in fact cleaner. One of the reasons being it's spartan syntax. It's one of the goals of the language. :)

PHP is just ugly, (see grandparent) Perl and Ruby are quite fun and share the same philosophy (see TIMTOWTDI) where Python is just the opposite (although fun too).

Python and Ruby also share their deep roots in clean object orientation, where Perl's OO syntax is - though bolted on - very flexible and even more TIMTOWTDI than Ruby's.

Just to set things straight, I really like Perl, Ruby and Python, though I can confirm that developing web applications with Django is bliss.

When Ken Thompson and Dennis Ritchie received the 1983 Turing Award, after their respective acceptance speeches, someone in the audience asked Ken what he would do differently with Unix if he were to do it all over again. He said, "I'd spell 'creat' with an 'e'."

Variables and functions can have names, and they should be meaningful. There are functions, classes, etc. to divide code into manageable parts. A part should do only one thing and do it well. Put parts with similar function in a group with a proper name. This is called self documenting code

Use comments to explain non-obvious solutions to a problem, for example if you had to work around a bug in an external library. Don't explain in a comment what is already concisely expressed in code.

Document interfaces. If you want other programmers to use your code, you should document the classes and functions they call. This will save them a lot of time and make your code more valuable, but it's a rather boring task. Not every project has such an interface.

Gah! Wikipedia, not "wiki". If anything deserves to be called wiki, it's the original one, which predates wikipedia by about 5 years.

Case in point: PHP's hybrid list/dictionary structure makes many otherwise-common cases tricky.

Well, in my opinion, PHP's odd dictionary is just bad language design. What people really want is light-duty in-app tables with some very basic relational query ability (simpler than SQL, but perhaps with SQL as an option).

More on this at:

http://c2.com/cgi/wiki?AreTablesGeneralPurposeStru ctures

http://c2.com/cgi/wiki?MinimalTable

Case in point: PHP's hybrid list/dictionary structure makes many otherwise-common cases tricky.

Well, in my opinion, PHP's odd dictionary is just bad language design. What people really want is light-duty in-app tables with some very basic relational query ability (simpler than SQL, but perhaps with SQL as an option).

More on this at:

http://c2.com/cgi/wiki?AreTablesGeneralPurposeStru ctures

http://c2.com/cgi/wiki?MinimalTable

Precisely. Because of things like the Ken Thompson hack to infect compilers invisibly, we know that even open source systems can be hijacked. We need physical records that cannot be modified as verifiable evidence that your vote was cast as you thought, and we need random checks to make sure that the voting machines aren't bad.

The world we would live in with [100% leisure time] is my biggest nightmare. The point of advancement is to answer questions. The more questions we answer, the easier life gets for sure, but you continue the quest to answer questions. We should never be content with where we are as a people.

I don't know about you, but I use my leisure time to research, to solve problems, to work on things interesting to me. The entire Open Source movement is about using leisure time to make useful, important things, mostly without pay. Do you seriously think that being able to provide food, shelter, and clothing for the entire world is a bad thing?

Scarcity is a problem. I don't know about "evil," but definitely a problem. Quite a few extremely talented people don't get to work at "furthering the species" because they're busy trying to get by. There are people starving in Africa who could do wonderful things for the human race if only they weren't dying from hunger. There are people working in sweatshops in Asia for pennies a day who could join you in your quest to answer questions if only they weren't using all their time to stitch up a shoe.

What do you think we're advancing for, anyway? If you don't have a goal in mind, how are you supposed to get there? When we get to the point that we can eliminate scarcity, I'd rejoice that I can finally stop working for a paycheck and start working for personal interest -- I can write the book I've wanted to, make another music album, work on the sufficiently smart compiler, and so on.

Scarcity is a barrier to advancement, not the reason for it.

This parable illustrates how personal defects get in the way of quality. If the code is crap, the code is crap, no matter who wrote it. If politics or sensitive egos block improvements, quality suffers. Compare EgolessProgramming.

This "my code is perfect" attitude is alive and well. A friend of mine started a new job recently and found that his boss:

• Considered himself in the top 1% of programmers
• Described every line of code he had written for the company's application as "perfect"
• Refused to use any version control system, yet was part of a team
• Wrote no comments, and no documentation

The syntax is just way too overblown - but then us Smug Lisp Weenies know that anything more than parens and a few lexical markers is overblown.

Look at the performance of the core 2 duo. There's no memory controller integrated because it hasn't been needed tet - YAGNI. As for AMD integrating GPU's, it's not exactly a new idea, and has been done before.

You are obviously not a software developer. Things you are asking for are not design limitations, they are technical limitations.

Media categorization based on content (images, music, etc) is just now stating to become viable due to new algorithms and faster hardware. Google probably has the infrastructure to do it, but your PC doesn't. It's not like what you see in the movies, computers are made for processing quantitative data, not qualitative data.

Sun attempted to make drag-and-drop program development/extension with their Java Beans, but the problem turns out to be much harder than you would think. You can't make a program do something it wasn't designed to do.

Maybe you would be happier with the HollywoodOS

#!/usr/bin/perl
use CGI':all';path_info=~/\w+/;$_=`grep -l $& *`.h1($&).escapeHTML$t=param(t)
||`dd<$&`;open F,">$&";print F$t;s/htt\S+|([A-Z]\w+){2,}/a{href,$&},$&/eg;
pri nt header,pre"$_<form>",submit,textarea t,$t,9,70

A better way out would be a successor to SQL that is more like a procedural language for objects with all operators/functions implicitly working on collections like tables.

If you mean like cursor-oriented approaches (explicit loops), that tends to make automatic optimization harder. If you note, in SQL you generally don't specify order nor explicit loops. The idea is that the RDBMS figures out the best performance path so that you don't have to. It is like refacting a math equation. The less your query language is like math and the more like procedural steps (loops and conditionals), the harder it is to auto-optimize.

As far as "objects", I think OOP set relational progress back 15 years. OO conflicts with relational on a number of fronts and has bloated up code with ugly translation layers. But that is another debate for another day.

As far as replacing SQL with a more flexible query language, I have proposed SMEQL (Structured Meta-Enabled Query Language). It allows things like column lists to be "calculated" via a query also. It also makes it easier to split big queries into smaller ones by using named references instead of (or in additional to) nesting. Some have complained about the "string clauses", but these are just one of multiple implementation approaches.

Once the design is complete - to a point where code monkeys can implement it....

I reject that premise: The Source Code is the Design.

Yeah, but how many co-authors did you use?

For my most recent book? One, but we've integrated suggestions from our editor and a couple of dozen reviewers. Even our outline has changed substantially from our proposal.

For my novel? None, but again, I've had detailed suggestions from one reviewer, input from several other readers, and specific comments from an editor. Also again, I didn't know where I'd end up when I started, and I'm very glad for that; the novel is much better for following the characters than a predetermined plan.