Live data from Hacker News

Why Isn’t Programming Futuristic?

ianbicking.org

71–80 of 85 posts

Re: Why Isn’t Programming Futuristic?

#71
post #5

I'm of the opinion that the way we interact with code is flawed. This author touched on it when discussing text dumps. I agree with the author that little time is spent modifying large modules of code (something NoFlow[1] is trying their hand at). However, I think these text dumps we work with should be organized differently. As it stands, we interact with code on a file-by-file basis. But any programmer knows that t…

I would love to be able to unfold method calls in my editor, something like(best I could do in ASCII)

  > hello_world()
    --------------------
      def hello_world
        puts "hello world!"
      end
and so on. Basically the code bubbles concept but inline. Maybe it'll be possible to get LT to do something like this in the future...

Re: Why Isn’t Programming Futuristic?

#72

Earlier quoted context omitted.

Tablet computers the pinnacle? They're fairly generic from a conceptual point of view. Pretty much the straightforward logical evolution of computing, as size gets smaller and computational power gets higher. Please don't mention the iPad as a pinnacle of anything. It is not. It is merely a rehash of old technologies packed into a slick exterior and heavily marketed. It is more a tool of social status than a utility.…

> Please don't mention the iPad as a pinnacle of anything. It is not. It is merely a rehash of old technologies packed into a slick exterior and heavily marketed. It is more a tool of social status than a utility. Compare this to the HP Compaq TC1100, which was a tablet computer released seven years before the first iPad and the specifications of which trumped those of the iPad by double. The iPad is more than heavil…

I had the TC1100, was able to pick it up cheap from liquidator of computers.

I had to figure out ways to undervolt the CPU so I could extend the battery. The battery typically lasted maybe 1-2 hours, but by undervolting I had gotten it to about 3. It was incredibly bulky and heavy, and it had no actual touch ability. It would heat up quite a bit.

Now the one good thing about it was it had a very accurate Wacom digitizer and man could it write notes. Shame there was never a good app for it.(OneNote maybe).

I think Microsoft took a cue from the way TC1100 provides a keyboard(not a shitty SurfaceRT one) that you can connect to and it's sturdy. Something I think the Surface is doing.

So overall not a usable device. My only question is that someone like Steve Jobs being around the same time never thought to release an Ipad at the time. I wonder why, did he think that the tech just wasn't ready hence not worth spoiling the user experience.

Re: Why Isn’t Programming Futuristic?

#73
post #64

Earlier quoted context omitted.

I'm starting to think that the reason we keep building tree-like data structures is because that's how our minds work. We can intuitively grasp hierarchies of categories (a tree structure), with the occasional exception (a symlink to another location). Because we intuitively see the world in this way, we are good at building and maintaining systems that work in this way. Anything more sophisticated than that (algebra…

> [Maybe] the reason we keep building tree-like data structures is because that's how our minds work. No. That's how physical space works. When you're a library, and you need your user to be able to find the books, you don't have a choice: any given book must be in one shelf, in one alley, in one room. And bam, you have a tree hierarchy that is three levels deep. But our minds are better at dealing with tags. Just se…

Both is better. There is no reason for the navigation system to ignore groups and hierarchies, it just should also be able to deal with arbitrary tags.

Having watched people struggle with what is essentially a configurable search pane (specifically, the excellent thumbnail viewer in Windows Live Photo Viewer), there does need to be a simple default, probably one that looks just like a hierarchical file system. It just shouldn't be the only way to use the system.

Re: Why Isn’t Programming Futuristic?

#74
post #64

Earlier quoted context omitted.

I'm starting to think that the reason we keep building tree-like data structures is because that's how our minds work. We can intuitively grasp hierarchies of categories (a tree structure), with the occasional exception (a symlink to another location). Because we intuitively see the world in this way, we are good at building and maintaining systems that work in this way. Anything more sophisticated than that (algebra…

> [Maybe] the reason we keep building tree-like data structures is because that's how our minds work. No. That's how physical space works. When you're a library, and you need your user to be able to find the books, you don't have a choice: any given book must be in one shelf, in one alley, in one room. And bam, you have a tree hierarchy that is three levels deep. But our minds are better at dealing with tags. Just se…

I spent sometime yesterday thinking about what queries I would like a filesystem (layout) to be able to answer.

-installed programs

-files installed (except configuration) by a program

-files installed (including configuration) by a program

-libraries

-a users personal files (including configuration).

-all files except bare bones install

-all files

-files on a specific hard drive

My conclusion was that my preferred layout would be

/os/ - bare bones install

/home/ - users files

/home/im3w1l/.conf/firefox - my configuration for firefox

/programs/ - installed program and libraries

/programs/libfuse/.conf - configuration for libfuse

/programs/firefox/.conf/im3w1l - my configuration for firefox

C:/programs - installed programs on specific hard drive

And that if a file is deleted from one place it is deleted from all. So rm /home/im3w1l/.conf/firefox -rf

would be the same as

rm /programs/firefox/.conf/im3w1l -rf

But I think a general tagged system has some problems, most notable filename collisions. Adding a tag to a file could create a collision for instance.

Re: Why Isn’t Programming Futuristic?

#75
post #2

Programming is futuristic in a 1950s sort of way. There's a classic Astounding Magazine cover from the era of a guy aggressively boarding a spaceship or something with a ray gun in his hand and a slide rule in his teeth. In other words, it's not futuristic because we're not terribly good at imagining the future. The guts of modern computing is based on the fundamental logical architecture of Von Neumann and others, w…

I recently had a need for an algorithm that did some pretty complex geographical data interpolation that was faster than the existing implementations. The modern vendor library I was using took about a minute to compute. I searched through some old archives and found a scanned in PDF of the algorithm I wanted to implement from a late 60s fortran implementation. I converted it to node.js and Presto! The thing takes th…

Fortran is totally known for its computational prowess.

Re: Why Isn’t Programming Futuristic?

#76

If you discard the idea of working with objects, and instead work with data structures directly, you get generic querying and transversal for free. A lot of these points look like they're solved by Clojure, but Clojure is my hammer, so perhaps it's cognitive bias that these look like Clojure-shaped nails.

Right. Actually a lot of the issues Bicking points out were handled by Lisps years ago. And you don't have to give op on objects per se: Objects in Clojure (with ad-hoc typing) can be treated as maps and darned near anything is seq-able in that Lisp dialect! Having s-expressions and macros lets you traverse and recombine things you could only imagine doing in Python. And don't even get me started on the power of lazi…

Objects in Clojure are an implementation detail of the JVM. Clojure doesn't really use objects as objects.

Records are, essentially, just maps with some type metadata attached. They're implemented as classes purely for performance purposes.

Re: Why Isn’t Programming Futuristic?

#77
post #56
post #36

I dunno, I think programming is pretty futuristic. We've got live coding, futuristic platforms, fast dynamic languages, etc... Of course, the most futuristic platform is right under people's noses, the browser. It does things that old Lisp programmers imagined, like live coding, even 3D games, with sound, and even Kinect-like motion control. Live coding: http://www.mrdoob.com/projects/htmleditor/ WebRTC: http://cbate…

Live coding => Smalltalk (1972), Lisp Machines (1979) Fast dynamic languages => Self (1986) WebRTC => oN-Line System (1968) It doesn't look very futurist to me.

"The future is already here — it's just not very evenly distributed." - Gibson.

Re: Why Isn’t Programming Futuristic?

#78
post #74

Earlier quoted context omitted.

> [Maybe] the reason we keep building tree-like data structures is because that's how our minds work. No. That's how physical space works. When you're a library, and you need your user to be able to find the books, you don't have a choice: any given book must be in one shelf, in one alley, in one room. And bam, you have a tree hierarchy that is three levels deep. But our minds are better at dealing with tags. Just se…

I spent sometime yesterday thinking about what queries I would like a filesystem (layout) to be able to answer. -installed programs -files installed (except configuration) by a program -files installed (including configuration) by a program -libraries -a users personal files (including configuration). -all files except bare bones install -all files -files on a specific hard drive My conclusion was that my preferred l…

For me a basic tag based file system needs several things: A unique ID for files (a strong cryptographic hash of the contents is probably best), a name for each file, and a list of tags for each files. And of course, a number of logical volumes on which the files are "located". Where a directory structure is actually needed, files could have special names, like "/os/glad/file_42" (that's a name, not a path).

A variation on this theme would be to do away with explicit names altogether, and only use tags. The "name" of the file would just need to be reasonably unique. That one is probably best.

Now, when you search for a file, you just query for tags. Can also be done through the shell: it's just that those two commands would have the exact same effect:

  cd /foo/bar
  cd /bar/foo
As for the volume, you need them to transfer files between your USB key and your computer.

Oh, thinking of using cryptographic hashes to name files… When you modify the file, the ID changes as well… that's a new file! By default, the old version should still be around. Imagine that: Git for the masses.

Re: Why Isn’t Programming Futuristic?

#79
post #22

Programming is futuristic. It's just that we can always imagine a better future -- and that's what makes programming so awesome. It enables us to build that future. But if you compare Ruby or Clojure to Forth or COBOL, there's no way you can't see how far we've come. And there's no end of improvement in sight.

Alternatively you could compare Ruby to SML and appreciate how far we've regressed.

Comparing, and... nope. They were both developed within a few years of each other, and are from different paradigms, so regression seems like a cheap dig, but not an accurate one.

Re: Why Isn’t Programming Futuristic?

#80
post #70

Earlier quoted context omitted.

> [Maybe] the reason we keep building tree-like data structures is because that's how our minds work. No. That's how physical space works. When you're a library, and you need your user to be able to find the books, you don't have a choice: any given book must be in one shelf, in one alley, in one room. And bam, you have a tree hierarchy that is three levels deep. But our minds are better at dealing with tags. Just se…

We could just put all the books in one, big room, just aisles and aisle of shelves, everything numbered sequentially. We could even build a library as one long hallway -- one single line of books. But we choose to divide our buildings up into rooms. We choose to create that hierarchy. Edit: I suppose, though, that our minds evolved to operate in physical space. Go hunt some zebra, go climb a tree... things like that.…

Even if you put the books on a single long shelf, chances are you're going to make the numbering system based on the content of the books, like say, the Dewey Decimal system. That's a hierarchy of at least two layers, right there. If you assign random identifiers, you'll probably end up creating that same hierarchy in the index instead, unless you do something more tag-based which is actually likely to be better.
Post reply on HN