Comment by chubot | Hacker News Reader

Comment by chubot | Hacker News Reader

Parent Full thread

It absolutely does need to be overhauled, but the problem is that people don't agree on the direction. I think most of your ideas are profoundly mistaken, and have been disproven by history. I'm sure you think my ideas are wrong too.

I think that people tend to dismiss the success or failure of certain systems as luck or even marketing, rather than deeply reflecting on the intrinsic properties of those systems that led them to be adopted or not adopted.

Unix and the web have lots of flaws, but they're not an accident of history. They have fundamental architectural properties that made them succeed. (In particular, REST is the same idea architecturally as Unix/Plan 9 style file systems. Long story, because it's basically avoiding O(m*n) problems in the ecosystem.)

You also have to accept evolution as a fundamental force in computing (as Linus Torvalds does). To ignore it is to set yourself up for failure and frustration. After all, humans are by no means the optimal living being either, but they're the best that evolution came up with.

And as I said in my other post, "revolutionary" ideas tend to just add to the pile. They fail to meet their expectations and then Unix subsumes them. It's almost an economic inevitability.

And Linux WAS revolutionary, if you compare to to Microsoft. The first couple decades of my life were DOS and Windows based, so from that perspective the revolution happened. Microsoft is porting all their stuff to Linux now.

http://www.revolution-os.com/

If you want a single language OS, check out Mirage: https://mirage.io/ . I know somebody is going to say "I don't like OCaml". Now you understand why Unix dominates: it supports heterogeneity. Even Mirage can't really get rid of Unix, because it runs on Xen, which typically runs on Linux.

I recognize that we disagree and I respect your opinion, I would just like to add a bit more:

> "have been disproven by history."

I guess that's my point. I don't think we've had enough history to be conclusive yet. I keep hearing this, over and over, and it's the equivalent of "heavier than air objects can't fly -- it's been proven in attempt after attempt."

In my opinion, the reason why there are thousands of programming languages, for example, and is not because we can't agree on them; it's because it hasn't been solved yet. No language is good enough, so we keep trying. In the late 1990's there were seemingly hundreds of search engines. Google/Page Rank came along and all the other search engines went away almost overnight.

> "revolutionary" ideas tend to just add to the pile

They do until they don't. All those crazy attempts at flight were truly crazy, until they lead to flight.

We're at the beginning of history, not the end of it.

Search engines are comparable in terms of how successful they are at their unique task.

Languages? What metric are you going to use that equally applicable to all tasks?

Think of it as vehicles and their different purposes. Would you support condensing all vehicles to one, so that one vehicle has to both haul and mix concrete and take your kids to get ice cream?

I think systems programming would continue to be separate. I left it off because it amounts to a small fraction of in terms of usage in terms of total code written (and I consider it to be able to be grouped in with hardware frankly).

The rest is application programming, and yes, when it's right, it will absolutely consolidate: There will be one "language". Sure, the current conventional wisdom is that languages are the "different tools in the toolbox." I know. My statement wasn't borne out of ignorance. What I'm saying is that kind of thinking is what's holding us back.

What is a program? Is it expressive text? Is it, "Shall I compare thee to a summer's day?" No, of course not. There's no narrative. We use text flow for instruction flow but that's coincidence. We are acutely aware that programs are discrete instructions. Code is data.

I made a statement above. I'll repeat it because it's important. It's a law: Data that is not stored or accessed as data eventually will be. Any programming language that uses text files will eventually go away. There will be one "language" eventually because the natural inclination of data is one representation. There will always be a market for new widgets to manipulate data or find insight in data, of course, but there will be one language -- and it will be data. It's the law.

Now I should admit, it's not that we haven't tried. We've tried many times and failed. What I'm saying is that if we come to a conclusion for a destination then there is no other choice but to make that the target.

I'm not fully grokking the theory/philosophy you're trying to express here, and I'd really like to, so I'll ask for forgiveness in advance if I seem too dense.

When I think of language and getting a message across (be it to someone else, or to a computer as code), I think of the components that are required for communication:

  - Emitter (myself) (EM; mostly obvious)
  - Recipient (someone else/the computer) (RE; also obvious)
  - Message (what I want to communicate) (MS)
  - Medium (what carries the message) (MD)
  - Protocol (base rules that both sides agree on) (PR)

If I'm trying to help my mother-in-law with a computer problem, I'll tell her to click on such-and-such over phone lines using English. (MD=phone line; MS=instructions; PR=English grammar)

If I'm writing a script to unzip a bunch of files at once and distribute the contents into different folders based on the file type, I'd probably whip up a Python script. (MD=text file; MS=task description; PR=Python)

My script in turn will communicate with the file system and the operating system to complete my task. (MD=bits; MS=instructions; PR=Python-to-Machine-Language-Interpreter)

If I understand you correctly, you're saying that all application programs should distill down to just the message, as the one representation of what I want to communicate. I'm hesitant to accept that, since it tends to assume that both emitter and recipient can independently determine and adapt to the correct protocol when all they have is the message.

For example, my Python script will probably use the file extension as a heuristic for the file type, but will make an error when picture.txt actually is a badly named JPEG. If I want to increase correctness, I can change the script so that it uses the file's Magic Number, but that may be overhead I don't need if the files are correctly named. Choosing one technique over the other requires that I craft the message differently, because Python doesn't make a decision on how best to determine file type.

TL;DR: Data needs a protocol to be used as information, and languages provide that. Doing away with languages means we need to define and agree on a non-ambiguous way of reading data, which is a tall order.

You raise an interesting point. Data, as we use it today, is often bare-bones and without meta-data. How you interpret it is very much up to you. It's as if, in English, we said "... apple ... tree" and then leave it to the user to decide if that's "I'm planting an apple tree" or "You can't get an apple from a walnut tree."

You're definitely describing how we work in today's terms -- there's nothing wrong with that, I'm just challenging it. I'm saying that we can describe the protocol better using data; or more I'm saying that it is data and that any other way of describing it is sub-optimal and for that reason will eventually desist.

> Doing away with languages means we need to define and agree on a non-ambiguous way of reading data Actually I'm saying that language is more ambiguous than data -- at all times and in all cases. Anything you can get language to do, you can get data to do better (in this context). But it's not a hard case to prove because actually we're using language as data. We're doing the equivalent in programming languages of typing in "three hundred" into a text file and having it read from the text file and converted to a single data unit of 300.0 when we could just be operating directly with the data.

But I didn't clarify how this would happen, so I can see that it would seem a bit abstruse. I need to better communicate and clarify that we need to expand how we're viewing data and how we work with data -- that we need to incorporate more meta-data as an ancillary part of the data that both comes with it and yet is still secondary.

Reply on news.ycombinator.com