7 ms·

I am building a new programming language that I have named Kitten, with a new paradigm I call modular. Modular programming will be as easy to learn as procedura

I am building a new programming language that I have named Kitten, with a new paradigm I call modular. Modular programming will be as easy to learn as procedural and as powerful as object oriented. I also plan to make the language nearly as fast as C but with Python styled syntax and with a good set of libraries and data structures. My language will not use manual pointers (no memory leaks or access violations), but will also not have garbage collection or reference counting, I have an idea to make things simpler, though it may add a few restrictions to the language. It will also be easy to extend the language from C, so any C library will be able to be used if a small wrapper is built (though of course errors in that part of the code could introduce memory leaks and access violations could occur). I have many more ideas I am adding to the language, those are just a sample of what I have planned. I have most of the language's details written up in pseudocode, hope to have a working Hello World in a month, a working prototype to give to friends in half a year, and a working prototype to post on Hacker News in a year, and a full language within 2-3 years. My problem is I am doing this on my own (which I don't want to change at this point) while working a full time job. I have thought about doing a Kickstarter to raise funds (I would ask for at least $100,000) but know the legal side of things means it would be unwise to do that until I create a company, which then would cost about $400 a year. I also don't want any kind of deals involving giving away pieces of the company, or going into debt, so donations are probably the only way I'd go. Does anyone think the Kickstarter would be worth it?

smt88 12y ago
Advice: don't do Kickstarter. A successful campaign is a full-time job by itself, and you need to have a hell of a knack for marketing to pull one off. Plus, your target market is going to groan at the idea of yet another new language. To reach them, you're going to need something that's fully usable and has a concrete use-case. For example, a lot of people have been announcing feature-complete languages that transpile to JavaScript, so they're usable right now. Two questions: 1) How is "modular" programming not possible in other languages? In something like Scala, I'd always imagined any paradigm is possible. I'd be extremely interested in a short piece of example code. 2) Why a new language instead of contributing to, say, Go, Rust, Scala, or one of the other "new" languages? It generally takes 5+ years for a language to become mainstream (sometimes much longer), so if you're looking at a release date of 3 years from now, you're talking about nearly a decade.
- KittenLanguage 12y ago
  Thanks for your advice! Modular programming is certainly possible in other languages, the same way object oriented programming is possible in procedural languages. I believe that starting from scratch will allow me to create a much easier to use language compared if other languages were given the capabilities I am adding. One example of this I have seen is a language called AutoIt, which is a very small language and I am amazed at how easy it is to program. One of my goals with Kitten is to make it capable as a teaching language, but also as a large project language, similar to Python. I simply love the unrestricted feel of every capability being useful. As a contrast, I spent a lot of time with C++ in the last year, and I am constantly amazed at how much more difficult programming in it is because of older concepts. In particular, strings have caused a lot of problems, due to the many many varieties of strings between C, C++, and Microsoft data types, as well as Ansi vs Unicode and const vs non-const. There's just so much more to learn, and a lot of it is older concepts that aren't very useful. Over the last year I have built a set of ideas that I have now gotten to play well together. These ideas include very specific syntax unlike any programming languages I have seen out there so far. I admit I have not tried many of the newer languages, but I hit a certain point where I didn't care what else was out there, I just had to build my ideas. Of course, if I do go into the Kickstarter route, I'd investigate those languages more first, right now I just decided to put something out there to see what people's first impressions were. Thanks for your input!
  - smt88 12y ago
    Using C++ and then deciding there needs to be a new language is a very common reaction. In fact, D and Go are exactly that: a replacement for C++. There are literally dozens of other languages that have an identical genesis. I think you found AutoIt to be simple and easy because it's not a general-purpose language. It has a very specific use-case and domain. I really wonder if you know how unbelievably complex and difficult it is to create a new language. Even very minor considerations become incredibly important for certain applications. If you really want to get this language off the ground, I'd suggest targeting JVM[1], CLR[2], or transpiling to JavaScript (basically the same targets as Clojure). Before you go any further, you should also actually spend some time with the new kids on the block. D is a direct successor to C++. Go is a C++ replacement. Rust is a general-purpose language aimed at web applications, and it was partly the inspiration for Swift. All of these are many years old, have the backing of a large corporation, are written by teams of brilliant people, or some combination of those things. It's really a massive undertaking, and most new languages fail or never get to a usable state. Don't you think it's possible that one of the tens of millions[3] of programmers in the world has developed something[4] you'd like as much as your theoretical language? 1. http://en.wikipedia.org/wiki/Java_virtual_machine http://en.wikipedia.org/wiki/Java_virtual_machine 2. http://en.wikipedia.org/wiki/Common_Language_Runtime http://en.wikipedia.org/wiki/Common_Language_Runtime 3. http://www.infoq.com/news/2014/01/IDC-software-developers http://www.infoq.com/news/2014/01/IDC-software-developers 4. http://en.wikipedia.org/wiki/List_of_programming_languages http://en.wikipedia.org/wiki/List_of_programming_languages
dragonwriter 12y ago
> I am building a new programming language that I have named Kitten, with a new paradigm I call modular. "Modular programming" is already a term in wide use for a widely used programming style/practice [1], so if you have defined a new paradigm, you should probably call it something else. [1] see, e.g., http://c2.com/cgi/wiki?ModularProgramming http://c2.com/cgi/wiki?ModularProgramming and http://en.wikipedia.org/wiki/Modular_programming http://en.wikipedia.org/wiki/Modular_programming
- KittenLanguage 12y ago
  Thanks for the heads up, this is the kind of advice I was seeking!
frowaway001 12y ago
You appear to be advocating a new: [ ] functional [ ] imperative [x] object-oriented [x] procedural [ ] stack-based [ ] "multi-paradigm" [ ] lazy [x] eager [ ] statically-typed [ ] dynamically-typed [ ] pure [x] impure [ ] non-hygienic [ ] visual [x] beginner-friendly [x] "modular" [x] non-programmer-friendly [ ] completely incomprehensible programming language. Your language will not work. Here is why it will not work. You appear to believe that: [x] Syntax is what makes programming difficult [x] Adding more "ideas" to a language makes it better [x] People choose between garbage collection/ manual memory management/reference counting and other, very hard to implement and use approaches for fun [ ] Garbage collection is free [x] Computers have infinite memory [ ] Nobody really needs: [x] concurrency [ ] a REPL [ ] debugger support [ ] IDE support [ ] I/O [ ] to interact with code not written in your language [ ] The entire world speaks 7-bit ASCII [ ] Scaling up to large software projects will be easy [x] Convincing programmers to adopt a new language will be easy [ ] Convincing programmers to adopt a language-specific IDE will be easy [ ] Programmers love writing lots of boilerplate [ ] Specifying behaviors as "undefined" means that programmers won't rely on them [x] "Spooky action at a distance" makes programming more fun [X] Programmers will pay money to use your language [X] Programmers aren't annoyed already from all the new free languages appearing twice a day Unfortunately, your language (has/lacks): [x] comprehensible syntax [ ] semicolons [x] significant whitespace [ ] macros [ ] implicit type conversion [ ] explicit casting [ ] type inference [ ] goto [ ] exceptions [ ] closures [ ] tail recursion [ ] coroutines [ ] reflection [x] subtyping [ ] multiple inheritance [ ] operator overloading [ ] algebraic datatypes [ ] recursive types [ ] polymorphic types [ ] covariant array typing [ ] monads [x] dependent types [ ] infix operators [ ] nested comments [ ] multi-line strings [ ] regexes [ ] call-by-value [ ] call-by-name [ ] call-by-reference [ ] call-cc The following philosophical objections apply: [ ] Programmers should not need to understand category theory to write "Hello, World!" [ ] Programmers should not develop RSI from writing "Hello, World!" [ ] The most significant program written in your language is its own compiler [ ] The most significant program written in your language isn't even its own compiler [x] No language spec [ ] "The implementation is the spec" [ ] The implementation is closed-source [ ] covered by patents [ ] not owned by you [ ] Your type system is unsound [ ] Your language cannot be unambiguously parsed [ ] a proof of same is attached [ ] invoking this proof crashes the compiler [x] The name of your language makes it impossible to find on Google [ ] Interpreted languages will never be as fast as C [ ] Compiled languages will never be "extensible" [x] Writing a compiler that understands English is AI-complete [x] Your language relies on an optimization which has never been shown possible [ ] There are less than 100 programmers on Earth smart enough to use your language [ ] ____________________________ takes exponential time [ ] The liveness property is known to be undecidable Your implementation has the following flaws: [x] The "market" for programming languages doesn't work this way (there is no market) [x] CPUs do not work that way [x] RAM does not work that way [x] VMs do not work that way [x] Compilers do not work that way [x] Compilers cannot work that way [ ] Shift-reduce conflicts in parsing seem to be resolved using rand() [ ] You require the compiler to be present at runtime [ ] You require the language runtime to be present at compile-time [ ] Your compiler errors are completely inscrutable [ ] Dangerous behavior is only a warning [ ] The compiler crashes if you look at it funny [ ] The VM crashes if you look at it funny [ ] You don't seem to understand basic optimization techniques [ ] You don't seem to understand basic systems programming [ ] You don't seem to understand pointers [ ] You don't seem to understand functions Additionally, your marketing has the following problems: [x] Unsupported claims of increased productivity [x] Unsupported claims of greater "ease of use" [ ] Obviously rigged benchmarks [ ] Graphics, simulation, or crypto benchmarks where your code just calls handwritten assembly through your FFI [ ] String-processing benchmarks where you just call PCRE [ ] Matrix-math benchmarks where you just call BLAS [x] Noone really believes that your language is faster than: [ ] assembly [x] C [ ] FORTRAN [ ] Java [ ] Ruby [ ] Prolog [x] Rejection of orthodox programming-language theory without justification [x] Rejection of orthodox systems programming without justification [x] Rejection of orthodox algorithmic theory without justification [x] Rejection of basic computer science without justification Taking the wider ecosystem into account, I would like to note that: [ ] Your complex sample code would be one line in: _______________________ [ ] We already have an unsafe imperative language [x] We already have a safe imperative OO language [ ] We already have a safe statically-typed eager functional language [ ] You have reinvented Lisp but worse [ ] You have reinvented Javascript but worse [ ] You have reinvented Java but worse [ ] You have reinvented C++ but worse [ ] You have reinvented PHP but worse [ ] You have reinvented PHP better, but that's still no justification [ ] You have reinvented Brainfuck but non-ironically [x] The "I can do everything better than thousands of people with decades of experience"-one-man-projects usually go nowhere. In conclusion, this is what I think of you: [x] You have some interesting ideas, but this won't fly. [x] This is 95% wishful thinking. [x] Building a language is a great way to gain deeper technical understanding, but believing it's possible to earn money with it is ridiculous. [ ] This is a bad language, and you should feel bad for inventing it. [ ] Programming in this language is an adequate punishment for inventing it.

smt88 12y ago

Advice: don't do Kickstarter. A successful campaign is a full-time job by itself, and you need to have a hell of a knack for marketing to pull one off. Plus, your target market is going to groan at the idea of yet another new language. To reach them, you're going to need something that's fully usable and has a concrete use-case. For example, a lot of people have been announcing feature-complete languages that transpile to JavaScript, so they're usable right now. Two questions: 1) How is "modular" programming not possible in other languages? In something like Scala, I'd always imagined any paradigm is possible. I'd be extremely interested in a short piece of example code. 2) Why a new language instead of contributing to, say, Go, Rust, Scala, or one of the other "new" languages? It generally takes 5+ years for a language to become mainstream (sometimes much longer), so if you're looking at a release date of 3 years from now, you're talking about nearly a decade.

KittenLanguage 12y ago
Thanks for your advice! Modular programming is certainly possible in other languages, the same way object oriented programming is possible in procedural languages. I believe that starting from scratch will allow me to create a much easier to use language compared if other languages were given the capabilities I am adding. One example of this I have seen is a language called AutoIt, which is a very small language and I am amazed at how easy it is to program. One of my goals with Kitten is to make it capable as a teaching language, but also as a large project language, similar to Python. I simply love the unrestricted feel of every capability being useful. As a contrast, I spent a lot of time with C++ in the last year, and I am constantly amazed at how much more difficult programming in it is because of older concepts. In particular, strings have caused a lot of problems, due to the many many varieties of strings between C, C++, and Microsoft data types, as well as Ansi vs Unicode and const vs non-const. There's just so much more to learn, and a lot of it is older concepts that aren't very useful. Over the last year I have built a set of ideas that I have now gotten to play well together. These ideas include very specific syntax unlike any programming languages I have seen out there so far. I admit I have not tried many of the newer languages, but I hit a certain point where I didn't care what else was out there, I just had to build my ideas. Of course, if I do go into the Kickstarter route, I'd investigate those languages more first, right now I just decided to put something out there to see what people's first impressions were. Thanks for your input!
- smt88 12y ago
  Using C++ and then deciding there needs to be a new language is a very common reaction. In fact, D and Go are exactly that: a replacement for C++. There are literally dozens of other languages that have an identical genesis. I think you found AutoIt to be simple and easy because it's not a general-purpose language. It has a very specific use-case and domain. I really wonder if you know how unbelievably complex and difficult it is to create a new language. Even very minor considerations become incredibly important for certain applications. If you really want to get this language off the ground, I'd suggest targeting JVM[1], CLR[2], or transpiling to JavaScript (basically the same targets as Clojure). Before you go any further, you should also actually spend some time with the new kids on the block. D is a direct successor to C++. Go is a C++ replacement. Rust is a general-purpose language aimed at web applications, and it was partly the inspiration for Swift. All of these are many years old, have the backing of a large corporation, are written by teams of brilliant people, or some combination of those things. It's really a massive undertaking, and most new languages fail or never get to a usable state. Don't you think it's possible that one of the tens of millions[3] of programmers in the world has developed something[4] you'd like as much as your theoretical language? 1. http://en.wikipedia.org/wiki/Java_virtual_machine http://en.wikipedia.org/wiki/Java_virtual_machine 2. http://en.wikipedia.org/wiki/Common_Language_Runtime http://en.wikipedia.org/wiki/Common_Language_Runtime 3. http://www.infoq.com/news/2014/01/IDC-software-developers http://www.infoq.com/news/2014/01/IDC-software-developers 4. http://en.wikipedia.org/wiki/List_of_programming_languages http://en.wikipedia.org/wiki/List_of_programming_languages

dragonwriter 12y ago

> I am building a new programming language that I have named Kitten, with a new paradigm I call modular. "Modular programming" is already a term in wide use for a widely used programming style/practice [1], so if you have defined a new paradigm, you should probably call it something else. [1] see, e.g., http://c2.com/cgi/wiki?ModularProgramming http://c2.com/cgi/wiki?ModularProgramming and http://en.wikipedia.org/wiki/Modular_programming http://en.wikipedia.org/wiki/Modular_programming

KittenLanguage 12y ago
Thanks for the heads up, this is the kind of advice I was seeking!

frowaway001 12y ago

You appear to be advocating a new: [ ] functional [ ] imperative [x] object-oriented [x] procedural [ ] stack-based [ ] "multi-paradigm" [ ] lazy [x] eager [ ] statically-typed [ ] dynamically-typed [ ] pure [x] impure [ ] non-hygienic [ ] visual [x] beginner-friendly [x] "modular" [x] non-programmer-friendly [ ] completely incomprehensible programming language. Your language will not work. Here is why it will not work. You appear to believe that: [x] Syntax is what makes programming difficult [x] Adding more "ideas" to a language makes it better [x] People choose between garbage collection/ manual memory management/reference counting and other, very hard to implement and use approaches for fun [ ] Garbage collection is free [x] Computers have infinite memory [ ] Nobody really needs: [x] concurrency [ ] a REPL [ ] debugger support [ ] IDE support [ ] I/O [ ] to interact with code not written in your language [ ] The entire world speaks 7-bit ASCII [ ] Scaling up to large software projects will be easy [x] Convincing programmers to adopt a new language will be easy [ ] Convincing programmers to adopt a language-specific IDE will be easy [ ] Programmers love writing lots of boilerplate [ ] Specifying behaviors as "undefined" means that programmers won't rely on them [x] "Spooky action at a distance" makes programming more fun [X] Programmers will pay money to use your language [X] Programmers aren't annoyed already from all the new free languages appearing twice a day Unfortunately, your language (has/lacks): [x] comprehensible syntax [ ] semicolons [x] significant whitespace [ ] macros [ ] implicit type conversion [ ] explicit casting [ ] type inference [ ] goto [ ] exceptions [ ] closures [ ] tail recursion [ ] coroutines [ ] reflection [x] subtyping [ ] multiple inheritance [ ] operator overloading [ ] algebraic datatypes [ ] recursive types [ ] polymorphic types [ ] covariant array typing [ ] monads [x] dependent types [ ] infix operators [ ] nested comments [ ] multi-line strings [ ] regexes [ ] call-by-value [ ] call-by-name [ ] call-by-reference [ ] call-cc The following philosophical objections apply: [ ] Programmers should not need to understand category theory to write "Hello, World!" [ ] Programmers should not develop RSI from writing "Hello, World!" [ ] The most significant program written in your language is its own compiler [ ] The most significant program written in your language isn't even its own compiler [x] No language spec [ ] "The implementation is the spec" [ ] The implementation is closed-source [ ] covered by patents [ ] not owned by you [ ] Your type system is unsound [ ] Your language cannot be unambiguously parsed [ ] a proof of same is attached [ ] invoking this proof crashes the compiler [x] The name of your language makes it impossible to find on Google [ ] Interpreted languages will never be as fast as C [ ] Compiled languages will never be "extensible" [x] Writing a compiler that understands English is AI-complete [x] Your language relies on an optimization which has never been shown possible [ ] There are less than 100 programmers on Earth smart enough to use your language [ ] ____________________________ takes exponential time [ ] The liveness property is known to be undecidable Your implementation has the following flaws: [x] The "market" for programming languages doesn't work this way (there is no market) [x] CPUs do not work that way [x] RAM does not work that way [x] VMs do not work that way [x] Compilers do not work that way [x] Compilers cannot work that way [ ] Shift-reduce conflicts in parsing seem to be resolved using rand() [ ] You require the compiler to be present at runtime [ ] You require the language runtime to be present at compile-time [ ] Your compiler errors are completely inscrutable [ ] Dangerous behavior is only a warning [ ] The compiler crashes if you look at it funny [ ] The VM crashes if you look at it funny [ ] You don't seem to understand basic optimization techniques [ ] You don't seem to understand basic systems programming [ ] You don't seem to understand pointers [ ] You don't seem to understand functions Additionally, your marketing has the following problems: [x] Unsupported claims of increased productivity [x] Unsupported claims of greater "ease of use" [ ] Obviously rigged benchmarks [ ] Graphics, simulation, or crypto benchmarks where your code just calls handwritten assembly through your FFI [ ] String-processing benchmarks where you just call PCRE [ ] Matrix-math benchmarks where you just call BLAS [x] Noone really believes that your language is faster than: [ ] assembly [x] C [ ] FORTRAN [ ] Java [ ] Ruby [ ] Prolog [x] Rejection of orthodox programming-language theory without justification [x] Rejection of orthodox systems programming without justification [x] Rejection of orthodox algorithmic theory without justification [x] Rejection of basic computer science without justification Taking the wider ecosystem into account, I would like to note that: [ ] Your complex sample code would be one line in: _______________________ [ ] We already have an unsafe imperative language [x] We already have a safe imperative OO language [ ] We already have a safe statically-typed eager functional language [ ] You have reinvented Lisp but worse [ ] You have reinvented Javascript but worse [ ] You have reinvented Java but worse [ ] You have reinvented C++ but worse [ ] You have reinvented PHP but worse [ ] You have reinvented PHP better, but that's still no justification [ ] You have reinvented Brainfuck but non-ironically [x] The "I can do everything better than thousands of people with decades of experience"-one-man-projects usually go nowhere. In conclusion, this is what I think of you: [x] You have some interesting ideas, but this won't fly. [x] This is 95% wishful thinking. [x] Building a language is a great way to gain deeper technical understanding, but believing it's possible to earn money with it is ridiculous. [ ] This is a bad language, and you should feel bad for inventing it. [ ] Programming in this language is an adequate punishment for inventing it.