Live data from Hacker News

Why Isn’t Programming Futuristic?

ianbicking.org

61–70 of 85 posts

Re: Why Isn’t Programming Futuristic?

#61
post #10

For the specific case of traversing objects (well, let's say data types), I think Haskell's lens library is the ultimate modern example. In fact, I think it basically covers everything he asked for in that section and more. It's quite a large library, for better or worse, so it really is complete. People have called it a "jQuery for data types", and that isn't such a bad description. It allows you to uniformly intera…

Does lens have a succinct way to traverse a nested data structure where each node is a maybe?

Lenses + Prisms (nicest way I know of in lens):

nested ^? foo . _Just . bar . _Just . baz . _Just

vs. the Maybe monad:

foo >=> bar >=> baz $ nested

Re: Why Isn’t Programming Futuristic?

#62
post #10

For the specific case of traversing objects (well, let's say data types), I think Haskell's lens library is the ultimate modern example. In fact, I think it basically covers everything he asked for in that section and more. It's quite a large library, for better or worse, so it really is complete. People have called it a "jQuery for data types", and that isn't such a bad description. It allows you to uniformly intera…

Does lens have a succinct way to traverse a nested data structure where each node is a maybe? Lenses + Prisms (nicest way I know of in lens): nested ^? foo . _Just . bar . _Just . baz . _Just vs. the Maybe monad: foo >=> bar >=> baz $ nested

I think that's basically it. You can check out a great example of prisms in the lens-aeson article on FPComplete:

https://www.fpcomplete.com/user/tel/lens-aeson-traversals-pr...

Re: Why Isn’t Programming Futuristic?

#63

Earlier quoted context omitted.

The iPad is the pinnacle of the marketing job of making people forget everything that came before :) But, seriously, Haskell, for example, is quite practical (better than the imperative languages) for a big set of applications. One problem is that people want a language to rule them all - and that language can only be imperative; the other problem is that people don't want to learn different things, and a new paradig…

Haskell has very good support for imperative programming.

People say this a lot, but I honestly don't think it does. Code written using monads, whether the IO monad or a custom monad stack provided by a web framework, tends not to play too nicely with other Haskell code. It kind of demands everything be on its own terms and isn't as simple, clear, and transparent as the best Haskell code can be.

Don't get me wrong, I love Haskell, but I don't think it's very good at imperative programming, and I think there are much better solutions to be found to problems such as I/O.

Re: Why Isn’t Programming Futuristic?

#64
post #47

Anyone who thinks we're using programming technology of the 70's probably wasn't programming in the 70's. Today it's routine to create systems in a handful of days that would have taken a larger team a much greater amount of time to create in the 70's, 80's, 90's, or even 00's. In fact, for years now, power users do certain kinds of applications with spreadsheets and similar tools-- without programmer intervention--…

C and Unix were invented in the 70's. Yes, things have improved a lot in the meantime, but underneath, it seems like a lot of the really basic paradigms are the same. We're mostly typing imperative code into a plain text editor, saved in a disk file in a tree-shaped filesystem, that probably runs on a Unix-like system. Maybe Windows, but in the space of all possible operating systems/environments, they're not that fa…

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, relational databases) requires a lot of study and practice to get good at.

Re: Why Isn’t Programming Futuristic?

#65
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…

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.…

I would say that the iPad is the pinnacle of "not having to think about anything".

Battery life is solid, unlike the tablets before (the figure I found for the TC1100 is 2-3h), the operating system is built for touch unlike Windows (or OS X). There are just no quirks to it that have to be explained by historical or technical circumstances. It just is. That's probably why it is so frustratingly non-futuristic :)

Re: Why Isn’t Programming Futuristic?

#66
post #27

Yeah, we're stuck with plaintext currently. This is because every time someone tries to write a better non-textual language, they fall into the trap of writing a cute toy or flowcharty bullshit--not a robust tool that scales to real codebases. And you can point to Smalltalk and Lisp machines all day, but they have to win, not be mere curiosities that lost gracefully. How do you write a structured code editor that win…

What happened to Grok? I heard it was going to be demoed after Steve left that project.

Re: Why Isn’t Programming Futuristic?

#67
post #64

Earlier quoted context omitted.

C and Unix were invented in the 70's. Yes, things have improved a lot in the meantime, but underneath, it seems like a lot of the really basic paradigms are the same. We're mostly typing imperative code into a plain text editor, saved in a disk file in a tree-shaped filesystem, that probably runs on a Unix-like system. Maybe Windows, but in the space of all possible operating systems/environments, they're not that fa…

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 see how popular they are in blogs. I bet that a tag based file system would be vastly better at storing personal data than a hierarchical one.

Re: Why Isn’t Programming Futuristic?

#68
post #17

The author never explains why all these features are desirable. Safe object traversal? Sure, reflection is a pain, but how would an improvement in this area bring us into the "future"? Also, I may have misunderstood, but isn't Lisp's object traversal about as safe as you can get? More/better ASTs? I think he was trying to say "compilers should have APIs for third-party tools". Otherwise I don't see why it matters whe…

Safe object traversal: if you can traverse objects you can start to create search algorithms (which is what Prolog's solver really is) that work across different domains and objects. I think this is a path towards goal-oriented programming. ASTs: by representing the program in a more abstracted way, we can start to build tools that manipulate them in ways other than ASCII editors. Direct manipulation of data: well, B…

A modern IDE already knows the AST it's working with in intimate detail - it has to, so that it can refactor it. But it's still displayed as (mostly) plain text, because that's still the best format for humans to read code (or indeed anything else) in.

Re: Why Isn’t Programming Futuristic?

#69
post #10

For the specific case of traversing objects (well, let's say data types), I think Haskell's lens library is the ultimate modern example. In fact, I think it basically covers everything he asked for in that section and more. It's quite a large library, for better or worse, so it really is complete. People have called it a "jQuery for data types", and that isn't such a bad description. It allows you to uniformly intera…

Does lens have a succinct way to traverse a nested data structure where each node is a maybe? Lenses + Prisms (nicest way I know of in lens): nested ^? foo . _Just . bar . _Just . baz . _Just vs. the Maybe monad: foo >=> bar >=> baz $ nested

That's the nicest I know as well. You could use `mapped` instead of `_Just` to make it more generic

    nested ^? foo . mapped . bar . mapped . baz . mapped
Which is also a bit closer to the nature of `>=>` chaining. I actually really like the _Just descent since it makes some of the failure modes for this lens very explicit.

And then it should always be said that the lens has setter properties that the `>=>` chain does not.

Re: Why Isn’t Programming Futuristic?

#70
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…

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...

Post reply on HN