Forgot your password?

Comment: Re:I, in turn, disagree (Score 1) 241

by ThePhilips (#47488895) Attached to: Math, Programming, and Language Learning

Man, I haven't even mentioned the numerical computing. It is an exception, because that's where programming serves the math, not the other way around.

In numerical computing, ironically, there is very little overlap between the math methods used in the development and math methods used for the goal of the development. Programs there often look more like a math formula. Developers simply skip the "computer science" as a whole and use the computers (with help of specialized libraries) as almost pure calculators.

As an exception, it is simply obscures the subject of the discussion.

The talk here is about what precisely from the math is used in general software development. (IOW, math serves the programming.) My personal experience, having majored in the applied math 15 years ago, is that by studying math one learns the methods to approach the real world problems. "Learns" is a weak word. The methods are implanted, grafted (or even brandmarked) onto the brain. Normal person's brain go into freeze when faced with thousands pages of specification. Person with math background, already switched into "divide and conquer" mode, and probably has already dismissed the >90% of it as trivial, incremental and derivative. (Some people learn it one their own. But studying math is definitely a nice shortcut to get there faster and earlier.) But the math in itself, either discrete/algebra or analysis or numerical, is very very rarely needed.

Comment: Re:I disagree (Score 1) 241

by ThePhilips (#47488019) Attached to: Math, Programming, and Language Learning

discrete math


Then it is fine. I would expect programmers to struggle with classical math geared toward physics. That's perfectly logical: it is easier for people who come from physics because they understand the applications. And vice versa: physicists have huge problems with discrete math, where you can't round or generalize everything to hell.

Otherwise, it was repeated many times before. The math in itself is not as useful as studying math is. Math doesn't relate to software development directly - but mathematical methods and approaches translate often one to one.

Studying math is fitness for the brains and method to the fitness.

P.S. But it doesn't mean that people who are good at math are good at programming too. Theoretical math != applied math. I have seen profs who could invent a new proof for theorem on a whim (forgotten notes), but struggled to implement something as trivial as a quick sort.

Comment: Re:Intel (Score 1) 236

by Wdomburg (#47476735) Attached to: Nearly 25 Years Ago, IBM Helped Save Macintosh

It was the G4 and a considerable level of creativity in Apple's marketing department. They were not considered a "supercomputer". They were briefly subject to an export ban to some markets because they breached a arbitrary limit that had already changed by the time they hit the market.

See, for example:

The extend of their superiority over the Intel and AMD processors of the time also need to be taken with a grain of salt. As with most Apple touted benchmarks, the fine print would reveal that the "up to twice as fast" claim referred to three specific Photoshop filters that were optimized for the Altivec operations in the G4. In other words, they exploited the fact that Intel made significant performance trade-offs with their implementation of SIMD instructions in that generation. In other benchmarks (like SPEC) the P3 spanked the G4.

Comment: Re:Perl 6ers just can't get shit done. (Score 1) 283

by Wdomburg (#47399579) Attached to: Perl Is Undead

That is the core API, not the standard library (csv, net/*, json, etc).

And again, that holds true for MRI Ruby, not every implementation. For example, in JRuby, this is:

/** rb_ary_push - specialized rb_ary_store
        public RubyArray append(IRubyObject item) {
                int valuesLength = values.length - begin;
                if (realLength == valuesLength) {
                        if (realLength == Integer.MAX_VALUE) throw getRuntime().newArgumentError("index too big");

                        long newLength = valuesLength + (valuesLength >> 1);
                        if (newLength > Integer.MAX_VALUE) {
                                newLength = Integer.MAX_VALUE;
                        } else if (newLength

And in Rubinius:

def push(*args)

        return self if args.empty?

        concat args

Comment: Re:Next Big Thing! (Score 1) 176

I've used emacs for that (editing 'uneditable' things in the buffer and then re-executing). See my post above - handy link here

OK. You completely miss the point.

Emacs' shell wrapper is just that: shell wrapper. Typing anywhere but at command prompt makes no sense. Command goes at the bottom. Output after it. Command at the bottom. Output. Rinse and repeat. You can't have (a) commands/outputs out of order, (b) non-shell commands or (c) re-execute in-place part of output as command.

Probably you simply never met with such problems so it is hard for you to even realize where from I'm (and apparently authors of xiki are) coming.

Comment: Re:Next Big Thing! (Score 1) 176

I dunno about the rest, but for filesystem browsing you can use vim :e on a directory which vim will then let you navigate

Well, you really have to try it first to understand the difference.

Browsing a directory in VIM - ':E' - shows you the content of directory in a buffer. What xiki demo shows is more of ^X^F (because you edit the path right in the editor window, with the rest of your text) but allowing you to actually dynamically run ^X^F on different parts of the dir/file name, changing content of the window accordingly. IOW, while ':E' is a dedicated browser, xiki does something like ^X^F to allow to edit/browse/etc inline, right in the middle of the text file, at any time when you need it.

And that's where the "innovation" comes. The tools to do all the things exist. But they all have different (and typically graphical) user interfaces. Xiki/etc try to combine the tools by putting them into an text editor, and making their output interactive and/or ready to be fed to the another tool. Because despite all the chrome, the basic nature of the content of the editor's window doesn't change: it is plain text. Commands are just text lines. Output are just text lines. It all becomes alive when special macro is run, which looks at the current line and tries to decide what to do with it.

Another way to look at it, and the way I often use my VIM hack, is that the same text file serves dual purpose: it is at the same time the script and the output of the script. The script and its output are interleaved. (That for example allows a very nice minor perk: rerun any command, flip between undo/redo and see the differences between then and now.)

Comment: Re:Next Big Thing! (Score 1) 176

Can you describe something that Xiki can do that cannot be done with `:r!`?

I can't. Because I do not use Xiki. I use something much simpler coded in VIM.

But the paradigm as I use it, in VIM terms: the command and the output are kept in the same editor window. You can apply exiting VIM functions to both - commands and output. You can save and load both at the same time - since in the essence it is an ordinary text file. With a special ':g//' I can rerun all the statements in file at once. Or I can selectively rerun only particular ones by the mask. I can ':w' and it is all made persistent. (My small creation was born first as a text file to keep the shell pipelines I use often. But with a VIM macro I have integrated also the output of the commands into the file. And then I given names to the commands. And then I allowed in pipes to refer to other pipes by the given names. After adding folding, it is still mostly looks like a text file with shell pipelines. Replaced bunch of terminals I used to keep open to run small monitoring/diagnostic commands. And a calculator, which I use most often (iow, a text file full of formulas, which I can copy/paste/modify and recalculate).)

Xiki, being a cross of Ruby and a text editor, apparently does more: it recognizes and presents as interactive not only the shell commands, but also the file system hierarchy, the Ruby code, the SQL statements, the CSS, the HTML, and probably more.

Computers are unreliable, but humans are even more unreliable. Any system which depends on human reliability is unreliable. -- Gilb