from the this.way.lies(["Madness",Libraries"]) dept.
Most programming languages come with built in support for handling common data types, however using and manipulating user-defined data types has to be done via general purpose syntax. This often leads to using Strings rather than structured data. Computer scientists have designed a safe way to use multiple programming languages within the same program, which will allow programmers to use the language most suitable for each function while also guarding against code injection. Their language, called Wyvern, is available as an Open Source Project.
The full paper is available as a PDF.
Wyvern determines which sublanguage is being used within the program based on the type of data the programmer is manipulating. Types specify the format of data, such as alphanumeric characters, floating-point numbers or more complex data structures, such as Web pages and database queries.
The type provides context, enabling Wyvern to identify a sublanguage associated with that type in the same way that a person would realize that a conversation about gourmet dining might include some French words and phrases, explained Joshua Sunshine, ISR systems scientist.
"Wyvern is like a skilled international negotiator who can smoothly switch between languages to get a whole team of people to work together," Aldrich said. "Such a person can be extremely effective and, likewise, I think our new approach can have a big impact on building software systems."
Many programming tasks can involve multiple languages; when building a Web page, for instance, HTML might be used to create the bulk of the page, but the programmer might also include SQL to access databases and JavaScript to allow for user interaction. By using type-specific languages, Wyvern can simplify that task for the programmer, Aldrich said, while also avoiding workarounds that can introduce security vulnerabilities.
One common but problematic practice is to paste together strings of characters to form a command in a specialized language, such as SQL, within a program. If not implemented carefully, however, this practice can leave computers vulnerable to two of the most serious security threats on the Web today - cross-site scripting attacks and SQL injection attacks. In the latter case, for instance, someone with knowledge of computer systems could use a login/password form or an order form on a Web site to type in a command to DROP TABLE that could wipe out a database.
(Score: 0) by Anonymous Coward on Monday August 11 2014, @03:37PM
How is this different than say SOAP or IDL before it?
The 'right' way to do this is usually by specifying an interface that each language hooks into each other.
Many times though badly done interfaces are nothing more than a string blob. But there are many examples of remote procedure call languages out there. For example SOAP, or COM, or even the RDP com is based on. Or even further back corba.
(Score: 5, Insightful) by Lagg on Monday August 11 2014, @03:45PM
To expand upon that, whenever these things come up I tend to wonder which of about 3 categories it's going to fit into: 1) Glorified preprocessor language 2) Glorified bindings or 3) Wrapper-style syntaxes similar to what knuth did with CWEB. Looking at the paper itself (I did not read the whole thing, I get fatigued from this stuff easily because of the sheer number of times I've seen it) it appears to be a bit of 1 and 3. It looks similar to LINQ for C#/.NET but more flexible. Stuff like this is always an interesting exercise in writing parsers but the practical application of it is questionable. I mean really eventually you're going to end up with something resembling lisp and perl if you follow it to its logical conclusion at which point you might as well just use lisp or perl...
http://lagg.me [lagg.me] 🗿
(Score: 2) by Theophrastus on Monday August 11 2014, @04:40PM
That was an interesting summary (and saved me a lot of effort) thankee!
are you asserting there's a Collatz sequence [wikipedia.org] convergence to all programming languages (and it's onto lisp or perl)? If so, you really ought to get your name on this conjecture to thereby assure your immortality [wink]
(Score: 2) by Yog-Yogguth on Monday August 11 2014, @06:34PM
I would answer "only Lisp" and "it's called Lisp" since every language (and everything else) can be written as Lisp (they're all subsets of Lisp).
One would hope that shouldn't be anywhere close to a controversial statement unless one claimed it was also trivial to do so in Lisp ;)
Bite harder Ouroboros, bite! tails.boum.org/ linux USB CD secure desktop IRC *crypt tor (not endorsements (XKeyScore))
(Score: 3, Informative) by VLM on Monday August 11 2014, @04:30PM
"How is this different than say SOAP or IDL before it?"
Looks like they're trying to embed strong typing into a defined cross language architecture. So no more stuffing an integer from javascript/jquery into a string in Perl into a float ending in .000 in the database, its all going to be integer across the board. Kinda sorta gross summation with plenty of mistakes but at least correct in spirit.
They're apparently just on the "mobile web" bandwagon for PR fun. Sounds more useful for embedded, avionics, life and safety stuff like that.
My operational experience with strong typing in non-life safety systems is the time saved in dumb easy to find and fix type mismatch accidents is more than made up for in debugging intentional type mismatches to work around major architectural mistakes and business changes.
Carried to their extreme, types end up being a pseudo-brittle-data-structure, and data structures being the PITA they are, the majority of the programming fraternity end up saying F all this I'm just shoving strings around now. What I'm getting at is a lot of "type stuff" is a conceptual patch on bad data structure design, and this is a patch on "type stuff". You'd be better off using data structures more advanced than arrays of java strings in the first place.
In the eternal circular wheel of IT time, this one doesn't look awful but does look like a bit of a time sink.
My extremely sarcastic analogy of a very strongly typed system is something like, One problem with traveling is getting lost and have no idea where you are or which direction to go. So the solution is to very firmly define the regex for your lat/lon, so ddd mm ss or ddd mm.mmmm or ddd.dddddddd or whatever. Then all your problems will go away. Oh wait, not all of them and now you're spending valuable thinking time working on complicated proven good math formulas to convert between lat/lon formats when your fundamental problem with getting lost was originally due anyway to not having good maps or a decent pathfinding algo or a good pattern matcher. Once you can find your arse with a map and a flashlight, then start worrying about making the hole strongly typed and type safe and all that. Of course 99.9999999% of software bugs are at the lower level of maps and flashlights and of course the type safety people advocate that all your problems will go away if you work on their pet topic first before the maps and flashlights problems are defined and figured out. In practice it mostly makes a lot of billable consultant hours.
So TLDR is its an interesting looking higher level patch on a system that I don't personally like very much that is itself a patch to force programmers to do things the right way, by some peculiar definitions of "right". All levels of the patching are worked around / avoided by bad programmers in order to successfully screw up and are not needed by good programmers resulting in little more than lots of noisy tire-spin across the board.
This is my crude analysis based on about 10 minutes of research. More paper reading might result in different conclusions, but probably not.
(Score: 2) by tibman on Monday August 11 2014, @09:53PM
That is a fun argument against strongly typed languages. More than once i've seen someone add a property to an existing data-structure out of laziness instead of making a new one. The modified structure works fine in that person's new code. They never tested all other other places it was originally used and cause run-time errors.
They have an implementation in scala: https://github.com/wyvernlang/tslwyvern [github.com]
Though it does not all appear to be written with readability in mind:
SN won't survive on lurkers alone. Write comments.
(Score: 5, Informative) by BradTheGeek on Monday August 11 2014, @03:39PM
This project is at least partially NSA funded. Do you want an NSA compiler building the programs that run on your hardware?
http://motherboard.vice.com/read/new-nsa-funded-programming-language-is-all-programming-languages-in-one [vice.com]
(Score: 3, Insightful) by Lagg on Monday August 11 2014, @03:48PM
Heh, this kind of project seems highly appropriate for a bureaucracy but in any case I wouldn't worry too much about it running on our hardware. To me this looks like another academic study that may at best be used internally.
http://lagg.me [lagg.me] 🗿
(Score: 3, Funny) by Zinho on Monday August 11 2014, @06:03PM
That matches well with the earlier suggestion [soylentnews.org] that once you've thrown all available languages together you may as well use Perl... [directessays.com]
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
(Score: 2) by c0lo on Monday August 11 2014, @03:45PM
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by tangomargarine on Monday August 11 2014, @05:12PM
How is mixing different liqueurs supposed to get you drunk faster? Unless you mean "putting more alcohol by volume in the same glass gets you drunk faster," in which case, yes, duh.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Monday August 11 2014, @05:23PM
This is why professional drinkers tend to pick a drink and stick with it.
(Score: 2) by FatPhil on Monday August 11 2014, @06:41PM
Putting more alcohol in the glass, and drinking it *in the same time, or quicker,* gets you drunk faster. Don't get all superior when you forget to mention the fundamental component - time.
And quite why you think mixing liqueurs will necessarily change the ABV, I don't know. Were I to mix two 18% ABV liqueurs, I'd expect almost exactly 18% ABV from the mixture.
(OK, there are secondary deviations to the rate of reaching drunkenness based on the final ABV of the mixture too. And of course things which are not a property of the drink at all, and thus out of scope.)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by tangomargarine on Monday August 11 2014, @09:11PM
This was precisely my point. Please reread my comment.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 3, Funny) by c0lo on Monday August 11 2014, @11:06PM
The main mechanism comes indeed from making you ingest more alcohol in the same amount of time. E.g. one of the most perverse mixture that I tried is beer "fortified" with vodka - the taste of beer will mask the usual dryness of vodka (which sorta slows your drinking in down); the likely effect is you'll tend to drink the mixture more like the way you drink beer than vodka. What make it so perverse: drunkenness is slow-ish to install (there's this delay until your stomach lining let pass enough alcohol, no matter how much of it you'd have) then it hits you like a train (because you likely had too much of it without realizing)
Not a fan of tequila myself, but the lime+salt combo will drive you to drink more of it
Translate this into "mixing programming languages" and you'll see the risk is pretty much the same: the taste of one language will mask the nastiness of other, so you'll write code faster and very likely not allow you enough time to think.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 4, Insightful) by tibman on Monday August 11 2014, @04:55PM
One common but problematic practice is to paste together strings of characters to form a command in a specialized language, such as SQL, within a program.
Nobody does this. If they do then they need to learn better methods (parametrized sql or use a dal).
Most languages use a middle layer that is really just a data structure to pass information back and forth. JSON is strings, yes, but it is not problematic. A static language will deserialize using a concrete object with types. An alpha character in an integer property will cause a deserialization failure, which is correct. You can even perform data-validation beforehand and return a better exception about why deserializtion won't work. Dynamic languages just don't care until run-time. In those cases you'll need data validation.
Packing type information along with the data itself is fine until you get into type conversion problems. Not every language supports every primitive data type. Which means you may be casting doubles to floats and so on. That can get nasty.
SN won't survive on lurkers alone. Write comments.
(Score: 5, Insightful) by Dunbal on Monday August 11 2014, @06:21PM
Because bug hunting isn't hard enough to do in just one language...
(Score: 0) by Anonymous Coward on Monday August 11 2014, @10:26PM
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them.
(Score: 3, Insightful) by cafebabe on Monday August 11 2014, @11:15PM
Because shoving HTML, CSS, JavaScript, PHP and SQL in one file isn't enough [soylentnews.org].
1702845791×2