5 ms·

The main page fails to communicate how the language is going to solve a users problems. The main page (which is what most people will only see) list the followi

by icefox 12y ago

The main page fails to communicate how the language is going to solve a users problems. The main page (which is what most people will only see) list the following features: Wren is small. Wren is clean. Wren is fast. Wren is class-based. Wren is a scripting language. If something is big, slow and message I don't care if it solves my problem when nothing else can. The only bullet point that comes close is the one talking about it being 'class-based', but I almost never hearing someone say "moving the code to classes will solve this problem". If that it is class based why would I use it over (as mentioned in the second sentence) Lua (or any one of the scripting "languages" that are just javascript in tiny form where I don't have to do any learning)? It seems like an easy pass for the majority of people that only read the main page. What problems do users that need an embedded scripting language have? Just guessing, but probably #1 is the difficulty of integrating it into their existing project (and ease of extendibility with my app). Followed by language compatibility, control over garbage collection, and docs so I can spend more time on my app and less time mucking with the scripting language. I am guessing that something like these are the pain points that the main page should talk about.

deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
alco 12y ago
First question in the Q & A here sheds light on the authors motivation for creating Wren: http://munificent.github.io/wren/qa.html#why-did-you-create-wren http://munificent.github.io/wren/qa.html#why-did-you-create-...
munificent 12y ago
I wrote a long reply, but HN apparently thinks I'm a spammer on this thread and ate it. :( Let me see if I can recall: > If something is big, slow and message I don't care if it solves my problem when nothing else can. This is true of a general purpose language. I'm sure most Ruby or Python users couldn't tell you the first thing about how big or complex MRI or CPython is. As long as it works, it works. Embedded languages are a different beast. When you drop something like Lua or Wren into your application, you're taking a direct dependency on its source code. You will end up stepping into in your debugger, reading its comments, etc. You will be shipping the language implementation itself physically with your application. When that's the case, having a small, clean implementation becomes a very important feature. > The only bullet point that comes close is the one talking about it being 'class-based', but I almost never hearing someone say "moving the code to classes will solve this problem". Syntax is about usability, not utility. It's almost never a question of "Can I do this using classes." Everything is Turing complete, so you could use Brainfuck as your scripting language. The key question is, "Is it easier, more enjoyable, and less error-prone to use classes?" If you're writing OOP-style code, which people increasingly do to script apps, I believe the answer is yes. Here's an example of that kind of object-oriented programming in Lua: Account = {} Account.__index = Account function Account.create(balance) local acnt = {} -- our new object setmetatable(acnt,Account) -- make Account handle lookup acnt.balance = balance -- initialize our object return acnt end function Account:withdraw(amount) self.balance = self.balance - amount end -- create and use an Account acc = Account.create(1000) acc:withdraw(100) Here's the same example in Wren: class Account { new(balance) { _balance = balance } withdraw(amount) { _balance = _balance - amount } } // create and use an Account var acc = new Account(100) acc.withdraw(100) I believe this is a real productivity and maintainability improvement, and productivity is exactly what scripting languages are for. > Just guessing, but probably #1 is the difficulty of integrating it into their existing project (and ease of extendibility with my app). Yup! That's also a key requirement (and one I still have a lot of work to do on.)
- TillE 12y ago
  In terms of embedding, are you planning on supporting C++ classes? For example, with Luabind (and a lot of wrapper boilerplate) you can define a virtual class in C++, create a subclass in Lua, then use that in all the nifty polymorphic ways you'd expect. In other words, will you have a more powerful C++ API on top of the plain old C API? Or is that a project for someone else, once Wren is a bit more mature?
  - munificent 12y ago
    That's a good question. Wren needs to support a non-C++ API because some potential users are using vanilla C. But I'm not at all opposed to also having a more class-based C++ API that wraps that. Whether I implement or someone else and whether it ships with Wren are open questions, but I'm open to pretty much any answer for them.
- j_s 12y ago
  I believe OP was pointing out an issue with the marketing... just copy a language as simple as Lua, but that feels natural to someone with an OOP background (or something similar) to your first bullet point! Edit: looks like your original comment made it through, and this repeat may best be deleted. Keep up the good work.
  - icefox 12y ago
    Yeah I was really just trying to point out that the marketing on the main page can be improved. I get that OOP can be a selling feature, but the other four not so much. Using the main page to talk about how great it does integration, how great the docs and examples are, and the API compatibility story are all things that would be better for convincing users to go to the next page. Using the funnel model how many users only viewed the main page and never went further?
    - munificent 12y ago
      > Yeah I was really just trying to point out that the marketing on the main page can be improved. I get that OOP can be a selling feature, but the other four not so much. It's a totally fair point. One thing I'm trying to keep in mind is who I'm marketing to. Right now, since Wren is so young, the people whose attention I want are not end users. They'd have to be half crazy to use Wren in its current state in a real application. The people that will take an interest now are those that are keen on new languages for their own novelty's sake, or that are interesting in contributing to Wren itself. That's the audience I had in mind, and I think the bullet points make a bit more sense when you consider that. Definitely, when Wren gets more mature, it makes sense to refocus the initial verbiage on what it can do for and end user.

by icefox 12y ago

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

alco 12y ago

First question in the Q & A here sheds light on the authors motivation for creating Wren: http://munificent.github.io/wren/qa.html#why-did-you-create-wren http://munificent.github.io/wren/qa.html#why-did-you-create-...

munificent 12y ago

I wrote a long reply, but HN apparently thinks I'm a spammer on this thread and ate it. :( Let me see if I can recall: > If something is big, slow and message I don't care if it solves my problem when nothing else can. This is true of a general purpose language. I'm sure most Ruby or Python users couldn't tell you the first thing about how big or complex MRI or CPython is. As long as it works, it works. Embedded languages are a different beast. When you drop something like Lua or Wren into your application, you're taking a direct dependency on its source code. You will end up stepping into in your debugger, reading its comments, etc. You will be shipping the language implementation itself physically with your application. When that's the case, having a small, clean implementation becomes a very important feature. > The only bullet point that comes close is the one talking about it being 'class-based', but I almost never hearing someone say "moving the code to classes will solve this problem". Syntax is about usability, not utility. It's almost never a question of "Can I do this using classes." Everything is Turing complete, so you could use Brainfuck as your scripting language. The key question is, "Is it easier, more enjoyable, and less error-prone to use classes?" If you're writing OOP-style code, which people increasingly do to script apps, I believe the answer is yes. Here's an example of that kind of object-oriented programming in Lua: Account = {} Account.__index = Account function Account.create(balance) local acnt = {} -- our new object setmetatable(acnt,Account) -- make Account handle lookup acnt.balance = balance -- initialize our object return acnt end function Account:withdraw(amount) self.balance = self.balance - amount end -- create and use an Account acc = Account.create(1000) acc:withdraw(100) Here's the same example in Wren: class Account { new(balance) { _balance = balance } withdraw(amount) { _balance = _balance - amount } } // create and use an Account var acc = new Account(100) acc.withdraw(100) I believe this is a real productivity and maintainability improvement, and productivity is exactly what scripting languages are for. > Just guessing, but probably #1 is the difficulty of integrating it into their existing project (and ease of extendibility with my app). Yup! That's also a key requirement (and one I still have a lot of work to do on.)

TillE 12y ago
In terms of embedding, are you planning on supporting C++ classes? For example, with Luabind (and a lot of wrapper boilerplate) you can define a virtual class in C++, create a subclass in Lua, then use that in all the nifty polymorphic ways you'd expect. In other words, will you have a more powerful C++ API on top of the plain old C API? Or is that a project for someone else, once Wren is a bit more mature?
- munificent 12y ago
  That's a good question. Wren needs to support a non-C++ API because some potential users are using vanilla C. But I'm not at all opposed to also having a more class-based C++ API that wraps that. Whether I implement or someone else and whether it ships with Wren are open questions, but I'm open to pretty much any answer for them.
j_s 12y ago
I believe OP was pointing out an issue with the marketing... just copy a language as simple as Lua, but that feels natural to someone with an OOP background (or something similar) to your first bullet point! Edit: looks like your original comment made it through, and this repeat may best be deleted. Keep up the good work.
- icefox 12y ago
  Yeah I was really just trying to point out that the marketing on the main page can be improved. I get that OOP can be a selling feature, but the other four not so much. Using the main page to talk about how great it does integration, how great the docs and examples are, and the API compatibility story are all things that would be better for convincing users to go to the next page. Using the funnel model how many users only viewed the main page and never went further?
  - munificent 12y ago
    > Yeah I was really just trying to point out that the marketing on the main page can be improved. I get that OOP can be a selling feature, but the other four not so much. It's a totally fair point. One thing I'm trying to keep in mind is who I'm marketing to. Right now, since Wren is so young, the people whose attention I want are not end users. They'd have to be half crazy to use Wren in its current state in a real application. The people that will take an interest now are those that are keen on new languages for their own novelty's sake, or that are interesting in contributing to Wren itself. That's the audience I had in mind, and I think the bullet points make a bit more sense when you consider that. Definitely, when Wren gets more mature, it makes sense to refocus the initial verbiage on what it can do for and end user.