5 ms·

> The codebase is ... lovingly-commented [0] For what it's worth, I absolutely love reading this sort of spanning descriptive comments. It makes the code that

by abcd_f 12y ago

> The codebase is ... lovingly-commented [0] For what it's worth, I absolutely love reading this sort of spanning descriptive comments. It makes the code that much more interesting and gives it a healthy dash of personality. I used to work with a guy who'd have header files start with pagefuls of comments with ASCII diagrams, book references, complete design rationale and what not, only to follow with just a handful of rather terse declarations, which still would be immediately clear thanks to the preceding narrative. That was so damn beautiful. [0] https://github.com/munificent/wren/blob/46c1ba92492e9257aba6418403161072d640cb29/src/wren_value.h#L378-L433 https://github.com/munificent/wren/blob/46c1ba92492e9257aba6...

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?

by abcd_f 12y ago

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?