December: What technological innovation I'm looking forward to

[jack]

I could have found an answer that fitted this question and yesterdays question both, but I decided they were interesting in different ways.

Technological innovations I think we're groping towards, which I'm impatient to have already:

A programming language with a syntax as straightforward as python, but works like C++14 is trying to, of letting it all compile to blazing fast code, even for embedded systems, by default, but letting you easily use dynamic typing where you actually want it. And of letting you use static type checking MOST of the time, but lets you be as dynamic as you need when you actually need it.

Widespread 3D printing of replacement parts, etc. We're nearly there, but we're waiting for a slightly wider variety of materials, and a wider database of possible things. Where you can say "I want this £10 widget holder from the supermarket, but can I get one 30% longer if I pay extra? OK? Thank you!"

Private cars replaced by mega-fleets of robot taxis and universal good public transport throughout/between all population dense areas.

Everyone uses git, or another dvcs, and the interface is actually consistent and friendly for everybody.

Decent, standardised, change-tracking and formatting for non-plain-text documents that allows sensible merging. (OK, this seems to be two steps forward and three steps back, so maybe there's no point waiting for it, but I'd still like it! :))

Comments

[andrewducker]

The problem is that Python doesn't provide enough information to produce blazing fast code. It's a bit too high level.

Have you looked at C#, which _is_ really fast, and allows dynamic objects when necessary (but most of the time doesn't need them)?

[jack]

The problem is that Python doesn't provide enough information to produce blazing fast code. It's a bit too high level.

I am interested in how often this as actually true. My impression is that a lot of Python idioms could be translated into C++14, and they would be _unwieldy_ but could, in principle, be translated without losing information. (With the caveat that it's only fast if you can prove at compile time what the types can be, which is why I mention static typing: that 90% of the time, you DO know the types at compile time.) But I've not actually tested this idea. I'm not sure if it would be practical to actually DO that or not (it might take as much effort as all the decades spent developing C compilers).

[andrewducker]

Oh, and Git is perfectly friendly, so long as you use an interface other than the command-line.

And I use Word all the time to do change-tracking and formatting, with merging. Seems to work ok.

[jack]

Git is perfectly friendly, so long as you use an interface other than the command-line.

I need to actually try this. I think "non-friendly" is related to several different things: one is people who don't grok command lines at all; one is the fact that the syntaxes to the command line tools are invariably inconsistent with each other in ways designed to make common tasks simple, but prevent easily generalising syntax; one is that it works on a somewhat different mental model to previous VCS (so people who are experience with SVN etc sometimes find it HARDER than someone who's never used VCS at all); one is that you can do quite complicated things but there may not always be a "right" way to do them. I'm not sure if you can fix all those things at once (but hopefully...)

[andrewducker]

The underlying model that git uses is actually quite simple, so once you understand that, working out what you want to do is easy enough.

The problem is the command line - and you can easily avoid that by using a tool like Eclipse (or various others).

[jack]

I use Word all the time to do change-tracking and formatting, with merging. Seems to work ok.

It does seem to have got better, I don't really have any experience of it, so it's likely it works better than I fear. Partly, even if it works technically, there still seems to be a big problem with people who don't, or can't, use it correctly, and documents with inconsistent versions, etc, etc getting emailed around... Partly, there seem to be lots of solutions for storing documents recording who changed what (like git for documents), but I've never heard anyone using one without swearing...

[andrewducker]

If the problem is "emailing documents of varying versions" then there's nothing you can do with a technological solution, except make people use it.

Git is text-only, which isn't very useful for merging documents that have any kind of complex syntax to them, or for adding comments to documents.

(You can use Github to do that with basic stuff, but it's not nearly as good as using Word's own "track changes" functionality.

[azurelunatic]

One of the things which is going to have to come along with the robot taxis and public transit is some way to haul a cubic meter or two of Stuff such that it can shuffle between modes of transportation pretty seamlessly. I can say from experience that it is unpleasant to haul groceries from a warehouse store grocery run on public transit. Perhaps you could make it a point-to-point robot taxi trip when you have that much Stuff, rather than trying to haul it between modes, but there would have to be pricing to make that work out.

One of the things which the transit is going to need to work out is capacity -- it's hard for me to travel on Caltrain when it's geared for peak capacity, because between pain, size, and flexibility, I need to sit in the accessible car. Off-peak, there are several. On-peak, there is one. It is anyone's guess which car that will be, so you can't accurately position yourself to board it, and the crowding is such that I can't actually walk between cars. In theory, people who do not need the moderately-accessible seats in the peak-capacity cars are supposed to give those up. In practice, groups of chatting teenagers have taken them and I am not actually up to the verbal communication necessary for telling them that I need a goddamn seat when I am already exhausted and in pain.

[naath]

Presumably robot-taxis are like current taxis - they come to where you are and go to where you want to be. Robot-busses would probably be cheaper, but of course less good for hauling Stuff(tm). Robot grocery-delivery-vans are also a possibility (my life contains zero "pack groceries to take home" because we have ours delivered, lucky us). I can shuffle lots of stuff (but not delicate food stuff, generally) by using a wheeled suitcase or a good rucksack (usefulness of same dependent on ability to carry them of course); supermarkets tend to put stuff into really useless bags, but perhaps the drive to get people to bring their own bag will result in people bringing bags that work better for them.

The very easiest thing your transit company could do is paint on the platform where the accessible car will be (and put it always in the same place); I wonder why this isn't done? The E* platform is painted with coach numbers for instance. That would need them to buy only a can of paint! There's a huge reluctance to paying for batter public transport, even in places where you have to play sardines if you want to use it to commute; I'm not really clear why that is, but it sucks.

[azurelunatic]

I wait at the "if you are on wheels board here" place. It doesn't always work.

[ciphergoth]

Have you looked at Rust? http://www.rust-lang.org/

[jack]

You're right! That does look to be very much what I was imagining. I'd heard it mentioned, but was one of several recent languages I wasn't quite sure what niche they were aiming for. Thank you! Do you have any experience with it?

[ciphergoth]

I've messed with it a little, I found it pretty difficult to get my programs to compile, like when you first learn Haskell!