This is pretty much the first question I ask every time I see a new language pop up.
The fact is the “language” part of a programming language is the easy part. The hard part is the ecosystem, tooling, mindshare, etc.
If your differentiation is “it’s 35% easier to do task A with my new language vs the next best alternative” then I am afraid you’ve lost me and I suspect most potential users.
The effort involved in learning your new system isn’t going to be amortized out by the benefits unless the benefits are very substantial.
This is coming from someone who really lives to learn new languages and is spending time most everyday working through new problems in new languages out of personal interest. For your average “just wanna get the job done” type you have an even more uphill battle.
Having said all that, it can be a great learning experience to build a new language and it’s always possible you’ll influence changes in preexisting systems that do have an existing user base, so I don’t mean to sound too discouraging to aspiring language designers.
The fact is the “language” part of a programming language is the easy part. The hard part is the ecosystem, tooling, mindshare, etc.
This is certainly true, but on the other hand, any new language that will one day be successful needs to start somewhere, or we're going to be writing systems code in bug-ridden C and line-of-business applications in verbose Java forever.
A language where doing day-to-day things would be 35% easier than what I use right now is certainly significantly better, IMHO. It seems to me that to move our industry forward by adopting newer and significantly better languages then a new language probably needs some or all of:
1. easy compatibility with a major existing library ecosystem (a simple FFI to any library with a C interface, for example) or a very comprehensive set of standard libraries out of the box and some tolerable way to integrate with more specialised ones
2. compatibility with existing tools or a decent version of the essential tools of its own (where "essential" today probably means something like build system, package manager, debugger, and maybe profiler, plus usable support in editors and things like version control and diff tools)
3. a compelling use case where it is much better than anything out there today, to act as a starting point for everything else to attach to
4. a core group of initial developers who are interested enough to do things with the language and help develop the above.
We discussed the problems with the ecosystems and I think you are right. Clio compiles to JavaScript, so it only makes sense to be 100% interoperable with the npm modules out there. We are currently working on that.
We want to provide an easy interface to quickly deploy decentralized services. Compared to alternative languages, the overhead to do so is much smaller with Clio
6700417|6 years ago
The fact is the “language” part of a programming language is the easy part. The hard part is the ecosystem, tooling, mindshare, etc.
If your differentiation is “it’s 35% easier to do task A with my new language vs the next best alternative” then I am afraid you’ve lost me and I suspect most potential users.
The effort involved in learning your new system isn’t going to be amortized out by the benefits unless the benefits are very substantial.
This is coming from someone who really lives to learn new languages and is spending time most everyday working through new problems in new languages out of personal interest. For your average “just wanna get the job done” type you have an even more uphill battle.
Having said all that, it can be a great learning experience to build a new language and it’s always possible you’ll influence changes in preexisting systems that do have an existing user base, so I don’t mean to sound too discouraging to aspiring language designers.
Silhouette|6 years ago
This is certainly true, but on the other hand, any new language that will one day be successful needs to start somewhere, or we're going to be writing systems code in bug-ridden C and line-of-business applications in verbose Java forever.
A language where doing day-to-day things would be 35% easier than what I use right now is certainly significantly better, IMHO. It seems to me that to move our industry forward by adopting newer and significantly better languages then a new language probably needs some or all of:
1. easy compatibility with a major existing library ecosystem (a simple FFI to any library with a C interface, for example) or a very comprehensive set of standard libraries out of the box and some tolerable way to integrate with more specialised ones
2. compatibility with existing tools or a decent version of the essential tools of its own (where "essential" today probably means something like build system, package manager, debugger, and maybe profiler, plus usable support in editors and things like version control and diff tools)
3. a compelling use case where it is much better than anything out there today, to act as a starting point for everything else to attach to
4. a core group of initial developers who are interested enough to do things with the language and help develop the above.
garritfra|6 years ago
garritfra|6 years ago