7 ms·
What happens when that 'higher level language' is the everyday language? Everyone knows it
by return0 10y ago
What happens when that 'higher level language' is the everyday language? Everyone knows it
- aianus 10y agoHow many people can describe an algorithm properly in English? Probably the same set of people that can program a computer.
- Zeebrommer 10y agoIt would take a lot less training however, if 'programming in English' was widely available.
- jdavis703 10y agoEnglish is such an ambiguous language, I would think that training would be a lot harder (especially for native speakers to unlearn the imprecise parts of English).
- pessimizer 10y agoEnglish is so ambiguous and so large that it would probably be best to reduce it to a strict, unambiguous vocabulary.
- dredmorbius 10y agoIt might take a few tries to get that right. We might see, say, "Unambiguas English version A", as an experimental or academic version. Then a trial "English B". And maybe on the third try, they'd get it right, say, "English C". We could call it "C" for short. (I know, I skipped BCPL.)
- PeterisP 10y agoProbably not. Currently, the part of training/learning time spent in educating developers that refers to the language syntax is at most 5% of the whole; perhaps 10% for the most junior developers; so 'programming in English' saves you just a tiny part of the training. However, as a specialized language can quite plausibly make you 10% or 100% more productive, no one serious would use general english even if it was a possibility. You might imagine a somewhat efficient programming in a very "jargony" english (similar to "legalese") with very specific (and likely unintuitive) meanings of a large number of particular phrases, but then there's no meaningful advantage of it, it's just as far from everyday english as any other programming language, and requires just as much training.
- cortesoft 10y agoYeah, you can see this in comparing how long it takes a person to learn a new programming language versus someone learning their first programming language. Learning a new language is trivial, learning to program not so much.
- sbmassey 10y agoI'd guess it would be more of a question-and-answer session between the computer and the designer rather than attempting to describe the algorithm up front.
- onion2k 10y agoVery little programming needs any algorithms though. Most of it is literally deciding what data to record, what validation rules to apply, and how to aggregate the collected data in to something useful. It's why MS Office is so prevalent - most business software is written in Excel with all the "code" abstracted in to forms and macros.
- contravariant 10y agoMore likely an even smaller set.
- k__ 10y agoTodays dynamically typed languages are already too ambiguous for most people to write correct software without tests, how should this get any better with using English? :D
- cookiecaper 10y agoYeah, I think this is the key. English is simply not specific enough to work as code. To the extent that "English" some day becomes a programming language, it will be a special dialect that looks an awful lot like something along the lines of SQL.
- majkinetor 10y agoYeah, because current paradigm in programming is about specification. When dominant paradigm becomes focused on probability, then English could become programming language.
- fmap 10y agoYour money was transferred to your account with 60% probability and donated to the Trump Foundation with 40% probability. Press escape or e to abort with 10% probability. So uhm... More seriously, what do you mean?
- pvg 10y agoThe tests are not because the languages are 'ambiguous'.
- new_hackers 10y agoUser: 'Make me a sandwich' *mighty robot slices up user and places in between two pieces of bread* Computer: 'You are now a sandwich'
- AtheistOfFail 10y agoSee, that's the issue, incorrectly specced software.
- taneq 10y agoExactly, so what we need to do is use a formalized language with strict rules to keep out any ambiguity. And then we fully specify what software we want and... this process is called 'programming'.
- AtheistOfFail 10y agoAnd then we can automate this 'programming' and people can ask the automation software to 'make them a sandwich'
- E6300 10y agoBut what if the programmer program could identify possible ambiguities and interactively ask you to clarify them? That would obviate the need for a formal language specification. >Make me a sandwich. Do you want to (1) be turned into a sandwich or (2) have a sandwich prepared? >2 What ingredients do you want in the sandwich? (etc.)
- marvin 10y agoThis is an agile development process. Although in principle it should be possible to have a machine that performs each iteration near-instantaneously, rather than wait three hours between each change.
- beaconstudios 10y agoI'm working in this space (check my profile) and I'm betting pretty heavily on the idea that the problem there is not the user's conception of their idea, but the flawed nature of language. If users can interact with their concept as they build it, and shape it like you would a physical product, they can get much closer to the ideal stored in their head than if they have to describe the idea in minute detail using ambiguous concepts.
- marktangotango 10y agoThis always makes me think of scene from Star Trek next generation when Geordie is on the holodeck trying to create a table. It takes 4 attempts for star fleets top engineer to get what he wants. I've often pondered this deeply illustrative example.
- RangerScience 10y agoEveryday language is made of leaky abstractions. Ruby is a good example of this direction; it's intended to (mostly / sometimes) read like actual english (RSpec is an even better example), but in the context of the language, Ruby's abstractions are precise, rather than the vague abstractions of human language. Additionally, there's a difference between "able to speak the language the computer can understand" and "able to program something"; that difference is "detail of thought". I tried to demonstrate this to a friend with a pretty good "Uber but for X" idea. I said - Okay, you want to rate people. Who rates whom? When? On what scale? What do you want each rating to mean? What do you use the ratings for? Following this train of thought - it's not JUST that we (as in the entire software engineering community) are adding levels of automation, it's that each higher level language adds "default" answers to those questions, so that at some point, you could just say: "Give me a rating system", and you'll get the usually-best one that you can refine; like the core CSS classes. We're rebuilding language from scratch, layer by layer, in order to have non-leaky abstractions. Or maybe we'll see something like the neural nets that can draw based off a phrase - you say "give me a rating system between users and drivers", and the NN generates something that satisfies, and then you refine from there - "give me a rating system... from 1-10, where normal service is a 7".
- mattkrause 10y agoWe already have this--contracts are "programs" that specify how other people should perform some action. Nevertheless, entire industries revolve around correctly writing contracts, making sure they are executed in the intended way, and resolving ambiguities and disputes about the original specification. If it's ever possible to go directly from English to running code, programmers will still be around; they'll just sound more like lawyers.
- booleandilemma 10y agoAgreed. You're always going to have people that manage the details and edge cases of complex software systems. Those people will be programmers. And if there is ever an AI invented that can replace those people then many white collar workers are at risk of losing their jobs, not just programmers.
- petra 10y agoAnd yet there's a lot of effort in automating lawyers, so maybe the future will be setting more higher level .
- visarga 10y agoHigher order lawyers - where you can do with one HOL in a day what took a month with regular lawyers (just like Python vs Assembler).
- TheOtherHobbes 10y agoContracts are not "programs", any more than programs are binding legal agreements between users. Lawyers are only paid to create clear specifications some of the time, and that mostly in criminal law and political legislation. In non-trivial corporate contract law they're paid to find favourable ambiguities in existing specifications, and to build possible ambiguities and hidden implications into negotiated agreements. They're also paid for their ability to use rhetorical, verbal, and theatrical tricks to persuade counterparties, judges, and juries of their point of view. Outside of STEM, the relative predictability of code is a very poor and superficial model for the relationships, transactions, and goals that define most domains.
- unscaled 10y agoProgramming languages have gradually evolved into higher levels of abstraction, but they haven't consistently become more humanlike. You can't fully understand human language with anything short of Strong AI. And yes, we made some progress in our ability to extract specialized meaning from natural language with high level of accuracy for things like translation or indexing - but we didn't get any closer to having computers understand and reason about the meaning of the text. In short, to say that we're rapidly getting to the point where computers can replace programmers in understanding natural language requirements and designing programs that achieve these requirements, you need to show consistent progress in general-purpose AI.
- fmap 10y agoThe elephant in the room is that programming in English would be a huge step backwards. Modern programming languages are all about scalable, modular abstractions. Natural language typically doesn't supply many sound abstractions. Everything you say is open to interpretation, as the many misunderstandings in this very thread clearly demonstrate...
- Ace17 10y agoYou no longer have to deal with solution domain issues (memory leaks, crashes, deadlocks, type errors ...). However, you might still need a huge bunch of english text to describe the problem domain. If such a text isn't already available, you need to write it yourself (coding). However, you might not write it in one shot, so you need to store it in text files that you can read and modify later. Maybe you would team with other people to write it, and you would share and track your modifications (versioning). Maybe, to make it easier to manage, you would split your description in multiple text files (modularizing). And then, you'd need a way to ensure that your text actually unambiguously means what you want. So you'd need ways to identify (testing) and correct (fixing) theses ambiguities. And maybe, at some point you would change your mind on some behaviours ; and then you'd come back to your description and modify it so future behaviours changes might be easier to deal with (refactoring). And also, maybe your intelligent system has inferred a correct way of doing things that is actually too slow. Maybe you could order "do it faster!", or maybe you would need to identify the source of slowness (profiling), and edit your description so a faster behaviour is inferred (optimizing). At this point, you in an attempt to improve your efficiency, you might consider using a simplified notation, which would be less-ambiguous and less verbose (like did scientists, musicians, engineers, mathematicians ...). See, nothing to do with programming!