8 ms·

The important use case is to allow people to write web applications with their language of choice, instead of horrible javascript. And get near full performance

by nwah1 11y ago

The important use case is to allow people to write web applications with their language of choice, instead of horrible javascript. And get near full performance.

klodolph 11y ago
I think this is important. Probably because I have the "worse is better" article from 1991 open in another tab, and if you s/Lisp/Javascript/g then many of the criticisms ring true. Some of what made Unix, Windows, and Mac OS healthy environments for development was the fact that all developers were equally well off, you didn't have to pay a tax for writing something in a language other than Lisp. You could keep your Fortran code, and mix it into a C program, run from a Bourne shell, running in terminal emulator written in C and a WM written in Lisp. You can replace any part with a part written in a different language. JavaScript will continue to be dominant, but we desperately need to be able to write things in the language of our choice.
- nostrademons 11y ago
  Hmm? You paid a huge tax in desktop development for writing in a language other than the one the OS was written in. All of the platform documentation & examples were in its "native" language. You usually had to marshall data structures yourself to fit the data formats of the native language. You had to write shims (oftentimes in assembly!) that would bridge the calling conventions of your preferred language to those that the frameworks were written in. There's a reason that C became the dominant language during the 80s and early 90s: it's because Win32, UNIX, and MacOS >=7 were all written in it. That's a large part of what Worse is Better was about. Richard Gabriel founded a company to write software for Lisp Machines, pivoted it to run Lisp on commodity hardware, found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business. The renaissance for other languages was really during the web era, when everything just spit out HTML and it didn't matter what the server was written in. Once customers started demanding rich interactivity on the client, there was a strong incentive to write everything in Javascript, and then a strong incentive to write the servers in Javascript too, and then a strong incentive to use Javascript for other things like native apps and IoT devices too.
  - klodolph 11y ago
    Yes, you paid a tax. But my argument here is that the tax for writing in different languages on Win32, Unix, and Mac OS was far cheaper than the tax for writing in other languages on a Lisp machine. This is because translating low-level code to high-level code is not as straightforward as the reverse operation. For example, if I compile C to JavaScript, how do I even think about writing a function like memcpy()? You end up with a monster like asm.js where interacting with the DOM is a chore. Yes, the web brought a renaissance in different languages. But we already had a bunch of different languages lying around when the web became important. We were already using different languages to write desktop software. I didn't even learn C until the late 1990s, but I was happily writing software before then. WebAssembly is going to make languages other than JavaScript palatable in the browser, and I can only see that as a good thing.
  - lispm 11y ago
    > Richard Gabriel founded a company to write software for Lisp Machines, The company Gabriel founded (Lucid Inc.) was never supposed to write software for Lisp Machines. Its mission from day zero was to develop a Common Lisp implementation for stock hardware (SUNs, etc.). Symbolics, the Lisp Machine maker, refused to fund a portable Common Lisp implementation (which Gabriel and Benson, the latter then at Symbolics, proposed). > found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business Actually the Lisp business of Lucid Inc. financed the C++ development. It was a gamble. They easily could have continued to develop and sell Common Lisp (their main competitors from that time, Franz Inc. and LispWorks are still alive) and stay in a small/shrinking niche. But Lucid tried to diversify and to grow. The idea was to write a C++ environment with a similar and improved development experience as a Lisp system. They used the cash cow they had and eventually sunk the whole company when the C++ system flopped in the market. Their C++ system (Energize) was very expensive, technically complex, ...
z3t4 11y ago
I think that's like saying: "I prefer to use the hammer instead of the screwdriver" for something with a helical ridge. You are better off re-inventing Java or Python, but in a container and streamed over the Internet from an URL.
jondubois 11y ago
I can't believe people still bash JavaScript. I've used a lot of different languages including Java, C#, C++, AVR Assembly, Python and others but JavaScript is my favourite and I would not want to go back. I think its a shame that some people just didn't seriously try JavaScript. It's a very powerful, expressive language. Also, testing with JS is amazing - Especially unit testing on Node.js. It lets you do stuff like redefine entire objects, properties or methods at runtime (for stubbing). Also, JS is great for writing asynchronous logic.
- cballard 11y ago
  I've tried JavaScript, and I decided I preferred type safety. This kind of thing: > It lets you do stuff like redefine entire objects, properties or methods at runtime Sounds horrifying to me, because, as in Ruby[1], library authors will decide that's a good idea. Typeclasses/protocols solve this problem perfectly, while maintaining type safety. [1]: for some reason, this seems to be less of an issue in Python and Obj-C, even though it's totally doable?
  - vardump 11y ago
    If type safety is what you miss, why not to use some transpiler like TypeScript? http://www.typescriptlang.org/Tutorial http://www.typescriptlang.org/Tutorial
    - cballard 11y ago
      Then you're not writing JavaScript, which was OP's concern. TypeScript is fine (although Elm, Swift, and Haskell are more interesting, IMO).
      - 1ris 11y ago
        Look at purescript. In order to install this madness you need to install not less than 5 package managers, but you might like it.
masswerk 11y ago
Sorry to say, but the web isn't about writing apps in the language of your choice. If it's beyond plain, passive HTML, it's about running applications on foreign hosts/resources without a well specified license to do so. Scripting languages provide both audible code and a small load as compared to binary object code (which is, why we had them on servers and clients in the first place). If we turn the web into an anything-goes bonanza using binary code without any keys, credentials, or permissions, WebAssembly (and Turing complete CSS as well) may be well the beginning of end of the web as we know it, giving raise to a new, leaner and more restricted platform (for which some are already on the lookout, BTW). [Edit] A small real world example: Client asks me to implement a third party plugin to allow them direct communications with their users via their website. A quick scan of the source code tells in a minute that the script isn't just doing that, but is also tracking user behavior and is phoning home related data. Now I can ask the client, if they really want to expose their users to this. With WebAssembly, there's no chance to do so.
- MichaelGG 11y ago
  Why are you under the impression there won't be disassemblers and decompilers for WebAssembly? It's not like a bunch of minified JS is going to be "quick" to go through.
  - masswerk 11y ago
    Even, if there would be a suitable disassembler, this would just account to an exponential curve in terms of auditing any software. (We're not speaking of minutes here anymore, but rather of months or even years – who will be willing to pay for it?) BTW, with minified JS, you've just to recode variable names (while anything adequate to system calls has to be in plain text somewhere by definition), with WebAssembly, this becomes an entirely different story. – No comparison.
    - MichaelGG 11y ago
      This is basically the same case for traditional binaries. I'm no RE expert, but when I've done such work it consists of "renaming variables" including functions and looking for calls to imported functions. Intentionally obfuscated code is harder. But nothing stops JS from loading a bunch of encrypted strings, self-modifying at runtime, using eval+substring (at various offsets) on loaded and renamed functions to make it hard to know if there are calls to other functions, let alone what they are. It can still be done, and obfuscated JS is probably easier than obfuscated x86 but saying it makes an audit only take minutes means it's not really being obfuscated.

by nwah1 11y ago

The important use case is to allow people to write web applications with their language of choice, instead of horrible javascript. And get near full performance.

klodolph 11y ago

I think this is important. Probably because I have the "worse is better" article from 1991 open in another tab, and if you s/Lisp/Javascript/g then many of the criticisms ring true. Some of what made Unix, Windows, and Mac OS healthy environments for development was the fact that all developers were equally well off, you didn't have to pay a tax for writing something in a language other than Lisp. You could keep your Fortran code, and mix it into a C program, run from a Bourne shell, running in terminal emulator written in C and a WM written in Lisp. You can replace any part with a part written in a different language. JavaScript will continue to be dominant, but we desperately need to be able to write things in the language of our choice.

nostrademons 11y ago
Hmm? You paid a huge tax in desktop development for writing in a language other than the one the OS was written in. All of the platform documentation & examples were in its "native" language. You usually had to marshall data structures yourself to fit the data formats of the native language. You had to write shims (oftentimes in assembly!) that would bridge the calling conventions of your preferred language to those that the frameworks were written in. There's a reason that C became the dominant language during the 80s and early 90s: it's because Win32, UNIX, and MacOS >=7 were all written in it. That's a large part of what Worse is Better was about. Richard Gabriel founded a company to write software for Lisp Machines, pivoted it to run Lisp on commodity hardware, found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business. The renaissance for other languages was really during the web era, when everything just spit out HTML and it didn't matter what the server was written in. Once customers started demanding rich interactivity on the client, there was a strong incentive to write everything in Javascript, and then a strong incentive to write the servers in Javascript too, and then a strong incentive to use Javascript for other things like native apps and IoT devices too.
- klodolph 11y ago
  Yes, you paid a tax. But my argument here is that the tax for writing in different languages on Win32, Unix, and Mac OS was far cheaper than the tax for writing in other languages on a Lisp machine. This is because translating low-level code to high-level code is not as straightforward as the reverse operation. For example, if I compile C to JavaScript, how do I even think about writing a function like memcpy()? You end up with a monster like asm.js where interacting with the DOM is a chore. Yes, the web brought a renaissance in different languages. But we already had a bunch of different languages lying around when the web became important. We were already using different languages to write desktop software. I didn't even learn C until the late 1990s, but I was happily writing software before then. WebAssembly is going to make languages other than JavaScript palatable in the browser, and I can only see that as a good thing.
- lispm 11y ago
  > Richard Gabriel founded a company to write software for Lisp Machines, The company Gabriel founded (Lucid Inc.) was never supposed to write software for Lisp Machines. Its mission from day zero was to develop a Common Lisp implementation for stock hardware (SUNs, etc.). Symbolics, the Lisp Machine maker, refused to fund a portable Common Lisp implementation (which Gabriel and Benson, the latter then at Symbolics, proposed). > found that all of his customers would rather just write in C, pivoted it again to do a C++ dev environment, and eventually went out of business Actually the Lisp business of Lucid Inc. financed the C++ development. It was a gamble. They easily could have continued to develop and sell Common Lisp (their main competitors from that time, Franz Inc. and LispWorks are still alive) and stay in a small/shrinking niche. But Lucid tried to diversify and to grow. The idea was to write a C++ environment with a similar and improved development experience as a Lisp system. They used the cash cow they had and eventually sunk the whole company when the C++ system flopped in the market. Their C++ system (Energize) was very expensive, technically complex, ...

z3t4 11y ago

I think that's like saying: "I prefer to use the hammer instead of the screwdriver" for something with a helical ridge. You are better off re-inventing Java or Python, but in a container and streamed over the Internet from an URL.

jondubois 11y ago

I can't believe people still bash JavaScript. I've used a lot of different languages including Java, C#, C++, AVR Assembly, Python and others but JavaScript is my favourite and I would not want to go back. I think its a shame that some people just didn't seriously try JavaScript. It's a very powerful, expressive language. Also, testing with JS is amazing - Especially unit testing on Node.js. It lets you do stuff like redefine entire objects, properties or methods at runtime (for stubbing). Also, JS is great for writing asynchronous logic.

cballard 11y ago
I've tried JavaScript, and I decided I preferred type safety. This kind of thing: > It lets you do stuff like redefine entire objects, properties or methods at runtime Sounds horrifying to me, because, as in Ruby[1], library authors will decide that's a good idea. Typeclasses/protocols solve this problem perfectly, while maintaining type safety. [1]: for some reason, this seems to be less of an issue in Python and Obj-C, even though it's totally doable?
- vardump 11y ago
  If type safety is what you miss, why not to use some transpiler like TypeScript? http://www.typescriptlang.org/Tutorial http://www.typescriptlang.org/Tutorial
  - cballard 11y ago
    Then you're not writing JavaScript, which was OP's concern. TypeScript is fine (although Elm, Swift, and Haskell are more interesting, IMO).
    - 1ris 11y ago
      Look at purescript. In order to install this madness you need to install not less than 5 package managers, but you might like it.

masswerk 11y ago

Sorry to say, but the web isn't about writing apps in the language of your choice. If it's beyond plain, passive HTML, it's about running applications on foreign hosts/resources without a well specified license to do so. Scripting languages provide both audible code and a small load as compared to binary object code (which is, why we had them on servers and clients in the first place). If we turn the web into an anything-goes bonanza using binary code without any keys, credentials, or permissions, WebAssembly (and Turing complete CSS as well) may be well the beginning of end of the web as we know it, giving raise to a new, leaner and more restricted platform (for which some are already on the lookout, BTW). [Edit] A small real world example: Client asks me to implement a third party plugin to allow them direct communications with their users via their website. A quick scan of the source code tells in a minute that the script isn't just doing that, but is also tracking user behavior and is phoning home related data. Now I can ask the client, if they really want to expose their users to this. With WebAssembly, there's no chance to do so.

MichaelGG 11y ago
Why are you under the impression there won't be disassemblers and decompilers for WebAssembly? It's not like a bunch of minified JS is going to be "quick" to go through.
- masswerk 11y ago
  Even, if there would be a suitable disassembler, this would just account to an exponential curve in terms of auditing any software. (We're not speaking of minutes here anymore, but rather of months or even years – who will be willing to pay for it?) BTW, with minified JS, you've just to recode variable names (while anything adequate to system calls has to be in plain text somewhere by definition), with WebAssembly, this becomes an entirely different story. – No comparison.
  - MichaelGG 11y ago
    This is basically the same case for traditional binaries. I'm no RE expert, but when I've done such work it consists of "renaming variables" including functions and looking for calls to imported functions. Intentionally obfuscated code is harder. But nothing stops JS from loading a bunch of encrypted strings, self-modifying at runtime, using eval+substring (at various offsets) on loaded and renamed functions to make it hard to know if there are calls to other functions, let alone what they are. It can still be done, and obfuscated JS is probably easier than obfuscated x86 but saying it makes an audit only take minutes means it's not really being obfuscated.