Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ask Slashdot: How Can I Make My Own Vaporware Real?

Posted by EditorDavid on from the real-soon-now dept.

Long-time Slashdot reader renuk007 is a retired Unix/Linux systems programmer with the ultimate question: After retiring I started a second career as a teacher -- and I'm loving it. My problem: I designed a (I feel) wonderful new language compiler, but implementing it will take me another ten years if I have to do it part-time.

Linus Torvalds was able to leverage the enthusiasm of the Internet to make Linux exist, but 1990 was a more innocent time. How does it work today? Any thoughts?
Or, to put it another way, how can you build a community to bring your ideas to light? Leave your best thoughts and suggestions in the comments. How can you make your own vaporware real?

69 of 128 comments (clear)

  1. new language compiler? by Anonymous Coward · · Score: 1

    so a new language or a new compiler?

  2. see, me by Anonymous Coward · · Score: 1

    I am more of an ideas guy

  3. Description? by Anonymous Coward · · Score: 5, Insightful

    You'll need to show someone *something*. Got a link to an abstract discussing why this compiler is so much better and worth the time investment? Not like there's a dearth of compilers of various designs out there.

  4. Here's how to do it: by Anonymous Coward · · Score: 5, Insightful

    Make the language simple enough so a simple parser will do.* Write a simple back-end that works, however inefficiently.

    Then publish.

    linus did it by publishing early and often. He also had the tide with him, building on a handy-dandy toolset, surfing on a wave of user demand for something, anything, that would make their computer go (linux really is very shoddy in its design and very far from the cutting edge, that was already the case right from the get-go), and you don't: There are too many pet languages already. But don't let that stop you. Write software that works, efficient comes later. Oh, and get with the documenting early on. Language specification, goals, non-goals, et cetera. Publishing early and publishing often is still a good start, and then there's the community building.

    * I'd like to mention the Crenshaw textfiles here.

    1. Re:Here's how to do it: by UnknownSoldier · · Score: 4, Insightful

      Pretty much this.

      "Ideas are a dime a dozen, its their implementation that is worth their weight in gold"

      Also a successful business must master "good enough." Build up the revenue stream and slowly add features. The late Steve Jobs knew this in spades. e.g. The first iPhone didn't have cut/copy/paste but it didn't need to.

      These days it is called Minimum viable product

    2. Re:Here's how to do it: by admin7087 · · Score: 1

      That's the reason why there is so much crap and fad software on the net that dies within 3 years after its invention.

    3. Re:Here's how to do it: by Provocateur · · Score: 1

      Agreed; when the creators see the numbers of early adopters, they think that that's it let's not follow through with what we were planning -- this one is good enough, and the numbers are attractive so far. The project develops inertia instead of momentum. The deliverable has yet to arrive; the minimal remains just that -- a mockup of what could have been And in three years it will be forgotten, or remembered as another wannabe.

      --
      WARNING: Smartphones have side effects--most of them undocumented.
    4. Re:Here's how to do it: by ZombieEngineer · · Score: 2

      I would second the recommendation of releasing a viable "proof of concept" for public comments.

      Twenty years ago (how time flies) I was part of a group of people who dealt with parallel port devices for Linux. A couple of newbies joined the Linux parallel port mailing list and started spouting about bus theory for sharing the parallel port for multiple device drivers. For the most part the participants on the mailing list were more interested in the practical side of getting their favorite parallel storage device working with Linux reliably than computer science theory. I responded to the newbies with a "put up or shut-up", in this case "please provide a header file of the routines that you would expect a parallel port sharing module to require". Dutifully the newbie responded over night with prototype header file and the next weekend (and about half a dozen kernal panics later) I coded up a variant of the lp & ppa driver with the relevant glue logic. This was posted to the mailing list and suddenly everyone jumped on the code and started porting existing drivers to the new architecture which shortly became known as parport.

      I must give additional credit to the newbie (I have forgotten the persons name) but he did get stuck into kernal hacking once the parport prototype was released. It is hell a lot easier to start modifying an existing code base than to start from scratch.

      ZombieEngineer

  5. "I don't mean to frighten you..." by stevegee58 · · Score: 4, Insightful

    "...but you'll have to do some actual work."

    --Dilbert

  6. New language compiler by tomhath · · Score: 1

    I seriously doubt you are talking about a new compiler, because you have virtually no chance of making one better than existing compilers for languages in use like C or Java.

    So I'm guessing you mean a new compiled language. Rather than Linux, look at the history of Python, it's closer to what you are thinking.

    If what you are proposing is neither a compiler nor a language than you need to learn a lot more about computers before anyone will take you seriously.

  7. Re:step one by Anonymous Coward · · Score: 1

    He might be able to hire help, at least for the initial development, on a site like Fiverr.

    But, before he gets started he really ought to discuss his idea with some people who have experience working with some experienced programmers to see just how good of an idea it really is.

  8. Tell people what you have.... then crowdfund? by intermelt · · Score: 2

    Maybe the simplest answer to your question is... Tell people what you have.

    Kickstarter or similar services are a great way to judge interest in a project. If you truly have something people will want, they will gladly donate to and share your idea. Of course this still requires marketing, maybe a break even type of thing. However with a niche offering like this, if you don't have a name or any way to prove what you can do, then don't expect much traction.

    Said in another way... if you aren't already known it will be very hard to become known.

    That being said, we can help without more information... New languages and/or compilers crop up every day.
    Have you invented a new language or just a new compiler? -- this is not clear at all.
    What makes you different from the others?
    How is it better?
    Why would I switch from what I am currently using?
    What is the learning curve to switch?
    What is is compatible with?

    1. Re:Tell people what you have.... then crowdfund? by intermelt · · Score: 1

      Oh and until you tell people what you actually have, it will always be vaporware.

    2. Re:Tell people what you have.... then crowdfund? by renuk007 · · Score: 2

      Okay, here's what it is. It's BASIC.

      I didn't want to make the intro too long, and I didn't want to turn off all the folks who think that BASIC sucks. But I programmed in it for ten years before switching to C, and I kept wishing that there could be a language that combined the speed of C, the friendliness of BASIC, the complex numbers and arrays of FORTRAN, the absolute reliability of COBOL's decimal math, and the stuff engineers always want like double-precision and FFT as built-in functions, and a bunch of connectivity options like hardware support and client/server connection implemented as pseudofiles, and painless implementation of shared-memory records, semaphores and locks.

      So I sat down to write it. Then I found myself "improving" things like almost every day, and finally, two years later, the only thing that was current was the reference manual, because I believe that the manual should state how the software should work, and the software should just shut up and do it.

      Don't get me wrong, I'm willing to do it; and I'm sure I can code (almost) every part of the design, but I can't do it in a realistic timeframe. My last project, which I did alone, was a set of servers for a banking application which had their own scripting language, and the banks running it have, over the last five years, developed a huge library of applications using that language, so I know that my work is reliable. And I've written terminal emulators, some graphic games for wyse-60/99 terminals that actually download code for the terminal itself, encryption and compression engines - you'll notice that most of this stuff is back-end programming. So I can code 90% of the design myself, and the rest is available as open source.

      And I love teaching. I absolutely want to keep doing it as long as I can, because the kids are willing to listen, unlike my colleagues for the past thirty years, and they think I'm funny, which is great for my ego. But I don't want to throw away all the design work that went into my language stuff, so now I'm willing to give away the ownership if somebody out there agrees that it's a cool idea, or wants to take it in a slightly different direction, or anything positive.

      Or I could just work on it quietly for the next few years, just like I'm doing now, but not making much progress. This is where I'm really conflicted.

    3. Re:Tell people what you have.... then crowdfund? by bzipitidoo · · Score: 1

      I hate that term "lamba". It's just a fancy term for "unnamed", or "anonymous". What is a lambda function? A function that doesn't have a name, didn't need to be named, that's all! They like to be a little more restrictive, in that if a function didn't need to be named, that's usually because it is of extremely limited scope, like inside another function, and apart from recursive calls, only called from its parent function.

      That kind of unnecessary jargon is representative of the entire field of programming language design. Because they are designing computer languages, they seem to feel freer to mess with English, and invent new, unnecesasry terms because they're such language geeks. I mean, "currying"? What's wrong with calling that "parameter unpacking" or something similar? But, why even bother with it, as its relationship to the meat of programming, which is to implement algorithms, is pretty tangential. Sure, useful for theory, same as a Turing Machine, but no one does any serious programming with a Turing Machine. The choice of font for the source code may be more significant than currying.

      Where it gets ugly for the humble application programmer are those cases where the designers insist on some limitation, claiming it is for the good of the programmers. Sometimes they admit it isn't about the programmer, but about simplifying the compiler. And then it turns out that the problem they were trying to relieve the compiler from solving was trivial for a computer anyway, so long as the computer has another measly 8k of RAM to spare. Like, Java forcing programmers to create separate files for each class. An even older example is the totally useless distinction Pascal makes between a Procedure and a Function, a hangover from Algol. And there's the bit about "strongly typed" (Pascal) and "weakly typed" (C), before scripting languages blew that debate away, taking a leaf from BASIC. By their standards, C is strongly typed, and Pascal is the strict disciplinarian schoolteacher from hell strongly typed.

      --
      Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
    4. Re:Tell people what you have.... then crowdfund? by amorsen · · Score: 1

      Almost every modern language is strongly typed. I struggle to think of a modern weakly typed language, but there must surely be some in the embedded space.

      You can perhaps argue that Perl is weakly typed, since you can do stuff like $a = '9'; print ++$a;. However, that is not really weak typing, it is just that the built-in Perl types have a really... imaginative set of valid operators. The string does not stop being a string just because you use an integer operator on it. This contrasts with C, where you can access the actual bit-representation of strings if you so desire, and there are rules that tell you reasonably precisely what you can expect to get out of that. Including the difference between behaviour that is undefined, implementation-defined, and a language extension.

      Static typing on the other hand is mostly gone, again probably with the exception of embedded. Dynamic typing is everywhere. I miss static typing sometimes when I debug.

      --
      Finally! A year of moderation! Ready for 2019?
    5. Re:Tell people what you have.... then crowdfund? by gunslnger · · Score: 1

      Plus, it has easy GUI design. And you can bring in C/C++ dlls or call python scripts if you really feel the need.

    6. Re:Tell people what you have.... then crowdfund? by gunslnger · · Score: 1

      Python is not strongly typed because it's not typed at all. That is what makes it a horrible language for programmers, but great for non-programmers.

    7. Re:Tell people what you have.... then crowdfund? by renuk007 · · Score: 1

      Here's some extracts from the manual's intro section. They should give a better understanding of the question "why?" The new language's tentative name is "STANDARD".

      Our goal with STANDARD is simple: to create a compiler which generates safe, fast code for processors which provide hardware memory protection and privilege control. Our starting point was C, arguably the most awesomely efficient language on the planet, but whose unbridled power exposes razor-sharp edges to the unwary. It is impossible for a C compiler to generate universally efficient safe code. In keeping with its first incarnation as the original systems language, C guarantees complete and unfettered access to the computer's hardware, including all memory without limitation. These implicit guarantees that C makes cannot be kept if in application mode, the hardware, for instance, will not permit random bits of data to be grabbed from anywhere in memory, or a chunk of data to be designated as executable code and forced to run. In C, string handling is simple but also incredibly dangerous - it is possible to overflow buffers, overwrite other data, and corrupt entire programs merely by concatenating two strings. Even by accident.

      Ideally, a compiler should be able to guarantee all features its designers wish to grant the programmer, and ensure that those features work uniformly and safely; and firmly forbid any other features that cannot be guaranteed. This would create a reliable framework with no unexpected behavior that leads to sudden crashes. But then user-level applications, by necessity, must deny operations that only make sense to operating-system level utilities; they should not permit actions that compromise security, hinder efficiency, or annoy other users. So C is not the answer.

      The safest language, historically, was COBOL. The largest repository of business programs, numbering in the millions, is now "legacy" code - because you could trust COBOL. Everybody appreciated decimal numbers that didn't give annoying binary fractions. But its wordiness and glacial pace didn't endear it to all, and the attempt to repair its unstructured jumping-around with the PERFORM verb was a pathetic failure that descended into monstrously sphagettified code - where the same paragraph could be simultaneously fallen-through and remotely PERFORMed.

      BASIC was loved by the vast majority. It was a simple language that made no unnecessary promises. Its processes and assumptions were very much in line with the philosophy of secure processors, because it was implemented from the very beginning as a multi-user system where it was important to play nice with others; and a little tweaking was all that was necessary to make a safe, friendly, efficient server applications programming language.

      Thus was born the concept of STANDARD: written in lightning-fast C, implementing the safety and reliability of COBOL and the friendliness of BASIC syntax, and incorporating the formidable mathematical toolkit of FORTRAN.

      STANDARD is not intended for front-end applications, having no GUI features, and supports only server-side events. It is designed to crunch data and to service requests, and to do these as fast and efficiently as possible. It retains and enhances BASIC's reputation as the best text processing language ever designed; it is also perfectly suited for batch processing, periodic processing and reporting; and obviously for embedded services. FORTRAN's awesome number-crunching power, which was partially given to BASIC, has been implemented in full with double-precision and complex number support. For accuracy in business applications, currency values may be computed entirely in decimal. In fact, STANDARD guarantees that its data types, from 18-digit numbers and petabyte strings to 10-dimensional complex-number arrays, will work efficiently out-of-the-box in every implementation, thereby removing all concerns about portability.

      In addition, the availability of certain software libraries is required. STANDARD uses the IBM Informix C-ISAM

    8. Re:Tell people what you have.... then crowdfund? by david_thornley · · Score: 1

      "Lambda" is a name with a long history. Back in the 1950s, John McCarthy came up with a language called LISP, that was partly based on Alonzo Church's Lambda Calculus. Lisp was a different approach at programming languages back then. FORTRAN was designed to compile to fast code, code that could compete with assembler for speed, while Lisp implemented programming principles at the cost of speed. For that reason, a lot of computer language development for decades was taking ideas from Lisp and implementing them in a language with a real syntax. Hence "lambda".

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    9. Re:Tell people what you have.... then crowdfund? by david_thornley · · Score: 1

      I'm having flashbacks to PL/1, which was IBM's idea for combining FORTRAN, COBOL, and ALGOL. It was not a tremendous success.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  9. leverage existing code... by Anonymous Coward · · Score: 1

    New language? can you write the front-end for LLVM? https://llvm.org/docs/tutorial/OCamlLangImpl1.html

  10. In other words: by AmazingRuss · · Score: 4, Insightful

    ""How do I get highly skilled, highly paid people to work on my idea for free?"

    If you figure that out, I'd love to learn it.

    1. Re:In other words: by Brett+Buck · · Score: 3, Funny

      I think its more like:

      "I have this idea about a machine that would transport matter instantly from one place to another, but I don't know much about physics, can someone flesh it out for me"

       

    2. Re:In other words: by hcs_$reboot · · Score: 1

      ""How do I get highly skilled, highly paid people to work on my idea for free?"

      If you figure that out, I'd love to learn it.

      Isn't that the principle behind stackoverflow and the like, where people sell skills in return for a bit of pride?

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    3. Re:In other words: by Chris+Mattern · · Score: 1

      Stackoverflow would like you to think so. In fact, it demonstrates that free advice is generally worth what you paid for it.

    4. Re:In other words: by Rande · · Score: 1

      Spending 30 minutes searching to see if my problem has already been solved to more or less an extent is time well spent. Sure, there'll be a lot of unhelpful junk to wade through, but it's still a lot more efficient than spending all day or maybe even a week tracing through code trying to find out exactly what is happening.

    5. Re:In other words: by WallyL · · Score: 1

      I think its more like:

      "I have this idea about a machine that would transport matter instantly from one place to another, but I don't know much about physics, can someone flesh it out for me"

      Easy!

      1. Design device that transports matter instantly from one place to another.
      2. ???
      3. Profit!

    6. Re:In other words: by david_thornley · · Score: 1

      It's fairly simple in concept. Executing this concept is left as an exercise for the reader.

      Design a piece of software. Make sure it fills a need. If it fills a need for you, that's a start.

      Get something out there that works and does something useful, using some sort of F/OS license. Put it on Github or somewhere like that, so people can find it and contribute code and documentation.

      Get people to use it, and incorporate their fixes and additions.

      Get some momentum going, and aim to make the software very good at what it does. Make it more popular.

      ???

      Profit!

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  11. It's called work by karlandtanya · · Score: 1

    Instead of trying to figure out how to get everyone else implement your ideas, how 'bout you get off your ass and start doing it yourself?
    Society does not exist to jump when you say frog.
    By asking the question you're just telling us you're a manipulative narcissist.

    --
    "Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
  12. Who cares? Really, find people who care by raymorris · · Score: 1

    "Get other people interested" is right, and I'd say start that by thinking about WHO would be interested. Would you project be useful? If so, to whom? Especially if certain industries or types of businesses would find it useful, write that down. Write down WHY it would be better, for them, than existing alternatives.

    As other commenters said "a new compiler" sounds questionable, and I wonder if you mean either "a new language" or a "translator from one language to another". If you're actually thinking a new *compiler* for an existing language, you probably have at least a thousand man-hours of work to do in order to get close to parity with existing compilers. Even then, doubtful it would make sense to write a whole new compiler; you'd instead either write a front-end for llvm or just use a compiler-generator like yacc, which automatically (and nearly instantly) creates your compiler for you.

    Note that a new language has to be a LOT better than the old, on technical merits, in order to replace the old because there is a large cost to switching. I've been studying C for years and I use tools and libraries that have been developed over decades, interacting with APIs written by thousands of people. A language with minor technical benefits wouldn't be worth learning not just the new language but new tools and libraries. That's one reason C is still very widely used 45 years after it was introduced. In the last 45 years, people have introduced languages that are objectively slightly better for the tasks C is used for, but none of those languages has been ENOUGH better to overcome the change cost for systems programming, embedded, etc.

  13. Get Zuckerberg by perry64 · · Score: 1

    He did a bang up job implementing the Winklevii's idea a few years ago. Also, there's some dissatisfaction with how he's doing his current job, so he might be looking for a new project.

  14. Re:step one by ShanghaiBill · · Score: 4, Insightful

    He might be able to hire help, at least for the initial development, on a site like Fiverr.

    People that are bad at development tend to also be bad at hiring developers, so most likely he would end up wasting money on incompetents.

    But the question is about getting people to work for free, not hiring help. Ideas are a dime a dozen, and it is extremely unlikely that he is going to get anyone to work on his, unless it is a really really good one ... and "new computer languages" tend to be the dumbest ideas of all. That is the last thing the world needs.

    And seriously, TEN YEARS to write a compiler? If he has a grammar (and if he doesn't, he has NOTHING) then just slap it into a parser generator such as Bison, and connect that to the gcc backend, or an existing parse tree interpreter, and you're done. That is a couple of weekends.

  15. Sorry, that's not how it works. by shess · · Score: 1

    You don't make a viral hit by saying "I want to make a viral hit, how do I do it?" You get started, release, provide details, show your enthusiasm by obviously putting more time into it, answer stupid questions over and over until someone starts helping, and you just keep it up. That would take all of 30 minutes to get rolling on Github.

    You provided ZERO details in your ask-slashdot! Literally none! So all signs currently point to you perhaps being unwilling to give up enough control to benefit from other people helping.

    If you're asking how to convince someone else to write the system for your language, haha, good luck, that's not how it works, people who have those skills don't need you as a source of ideas. Linus Torvalds succeeded by doing MASSIVE amounts of work himself, and others starts helping to a lesser extent. Also, he didn't wait for anyone else to start helping, he just started doing without concern for whether it was viable or whether anyone else would contribute. In other words, just do it, don't wait around for someone else to carry your water.

    1. Re:Sorry, that's not how it works. by 93+Escort+Wagon · · Score: 1

      You don't make a viral hit by saying "I want to make a viral hit, how do I do it?"

      A half-dozen boy bands from the past decade or so would like a word with you.

      Also chiming in to disagree is Milli-Vanilli, with the Spice Girls on backup.

      --
      #DeleteChrome
  16. Seek the Minimum Viable Product by J.+T.+MacLeod · · Score: 2

    You don't need a fully formed product to introduce your project to the world. You just need something that is complete enough to be useful.

    Maybe that's a feature-incomplete version. Maybe it's a moderately complete spec that can be used to build your goal. Maybe you start by building on some existing toolchain that you later plan to migrate away from. Whatever gets the project rolling fastest without sacrificing its core.

    Once you have that, then you can start getting people's attention. Post about it where people talk about programming and new language projects.

    Build it, and they will come. They will not come before you build it. So build *something*, even if it isn't finished.

  17. Re:step one by fahrbot-bot · · Score: 3, Funny

    And seriously, TEN YEARS to write a compiler? If he has a grammar (and if he doesn't, he has NOTHING) then just slap it into a parser generator such as Bison, and connect that to the gcc backend, or an existing parse tree interpreter, and you're done. That is a couple of weekends.

    Even faster if you hook it all up to the logic circuits of a Bambleweeny 57 Sub-Meson Brain and an atomic vector plotter suspended in a strong Brownian Motion producer (say a nice hot cup of tea).

    --
    It must have been something you assimilated. . . .
  18. Do we really need another language? by greenwow · · Score: 1

    Just this week I've programmed in Groovy for Jenkins, Java, JavaScript for client-side, C# for a web app, C++ for a desktop app, SQL stored procedures, Ruby for Puppet scripts, PHP for a web app, BASH, and PowerShell. We already have too many languages.

  19. Money by brian.stinar · · Score: 2

    I own a custom software development company. We accept money to turn vaporware into real software. Money is very useful for turning one thing into another, and was invented for exactly that purpose. Barter has many inefficiencies, and I prefer to use money rather than goodwill, community, equity, animals, vegetables, sexual favors, or IOUs, for creating software.

    1. Re:Money by Kjella · · Score: 1

      No offence, but with money you can have the equivalent of a vanity press. Like you'll have people writing code for you but nobody gives a shit.

      --
      Live today, because you never know what tomorrow brings
    2. Re:Money by Anonymous Coward · · Score: 1

      That was strategically misspelled to keep the client's expectations low. That allows them to ramp-up the work over a long period of time (i.e., obtaining more money with a slower pace).

    3. Re:Money by brian.stinar · · Score: 1

      Thanks. This is what happens when I have the intern add content with limited oversight... Don't hire us for copywriting.

    4. Re:Money by brian.stinar · · Score: 1

      Oh no, I've used the goodwill of the community to convince them to work on my project, for free!

  20. Sigh. by ledow · · Score: 3, Insightful

    If you can design a compiler and have any clue whatsoever about how to do so effectively, you can sure as hell break out another compiler and code it up.

    Then, once it's self-hosting, you can concentrate on the compiler itself.

    Like every "project" I ever got involved with or people asked me to join since I was a kid - it's the person with "all the ideas" who has no clue how to actually make the thing work, or what's even feasible. While the people who "can do" have a thousand such ideas throughout their life and can implement the ones that actually work and are feasible.

    Trust me, I've sat there for years thinking about ideal programming languages and game concepts and operating system design and all kinds of things. It's when you sit down and actually code stuff that you realise why it doesn't work, why it can't work well, why it's not so easy, and why the existing things were designed as they are.

    The "wow" moments come from someone MAKING IT HAPPEN and seeing that the lightbulb-moment can be real, never from just the moment or idea itself.

  21. How about linux for ARM by catsRus · · Score: 1

    Totally off topic! Why a new language? Lots of old ARM hardware out there just dying to broken out of the walled gardens from whence they came.

  22. Start by Archfeld · · Score: 2

    Start by recruiting your own students in a group or club, and then post a project to GitHub or Openhub.

    https://www.openhub.net/

    https://github.com/open-source

    --
    errr....umm...*whooosh* *whoosh* Is this thing on ?
  23. hard work by gravewax · · Score: 1

    You need to get your idea out their, WITH a good explanation/business case explaining why what you are doing is inherently better/innovative and worth the investment of time from others. You have a huge amount of long hours, hard work and persuading to do and you better have a very very good justification for the value of yet another language/compiler if you want anyone to follow.

  24. Don't reinvent the wheel by Locke2005 · · Score: 1

    We don't need another language, and compiler design pretty much peaked in the 70's. Try to build a community of interested volunteers, but if nobody is interested, that might be a clue that your idea isn't valuable enough to anyone except yourself.

    --
    I've abandoned my search for truth; now I'm just looking for some useful delusions.
  25. Find a group, then convince them by malxau · · Score: 1
    Being successful requires:
    1. Finding a group of people facing a similar problem with skills to contribute.
    2. Demonstrating enough value to them to justify their effort.

    These are both really (!) hard things to do. The software market is fairly crowded these days, so demonstrating you can beat existing offerings is hard. And although the Internet allows people to search fairly well, finding people facing similar problems is still really hard. It's not like you can show up on forums of a similar product, pitch your idea for a different thing, and expect to be well received.

    Realistically, don't start a software project if you're unwilling to be the only one working on it.

    (Personally I'm trying to build a decent native code Windows command prompt, and I can't believe others really think CMD is wonderful, or that managed environments are fun to use given their performance, or that sitting on emulation layers is a great way to interact with an OS. But the set of people who are passionate and skilled enough to act isn't that big, and they don't all hang out in the same place, so I'm still the only contributor, and I don't expect that to change imminently.)

  26. Re:github by packrat0x · · Score: 1

    If you do not follow their style guide exactly they flip out on you close the pull request and chase you off.

    Have people never heard of prettyprint and sed ? Or is this an organizing (function/procedure/module) conflict?

    --
    227-3517
  27. examples by bugs2squash · · Score: 1

    I suggest you write a few code samples in your new language and convince people that it has something captivating about it. You don't need a working compiler to write software, only to run it. And if you have already told people what to expect the output is they don't need to run it to find out.

    Here's an example of my new language

    10 ask what I want
    20 do it
    30 goto 10

    But seriously, if people see an elegant new way to solve a real problem they might go for it - eg. a way to tie in unit tests to the source code better, or a cool way to program in 3-d minecraft-like blocks

    --
    Nullius in verba
  28. Whip it out by Humbubba · · Score: 1
    Disclaimer: bullshit from the ignorati follows.

    1. Make an pre-announcement to popular geek sites - like you just did here. When it's ready, get both your targeted audience and vaunted coders to review the beast on those sites.

    2. Make a WEB site like PHP.net or SQLite.org, with announcements, news, conference and event dates, examples, comments, downloads, documentation, Q&A, important people info, email, sponsor and donation links, and thanks.

    3. Create a 501(c)(3) organization. If you want a viable community, it's gonna cost money. And tax-exempt is good for both you and your donors.

    4. Do what docker did, have a URL pointing to a QC'd step-by-step user-interface that lets the visitor create a simple little example, easy to grok, showing the language's power and potential.

    5. YouTube tutorials, starting with a beginner-friendly instructor who goes into an overview of the language's virtues, then writes and runs the obligatory 'Hello World!'. Next, the tutor explains the awesomeness of the language. The other tutorials that follow should have a similar format - somehow this makes it easier on the student.

    --

    In writing a new language, what are you going for? Is there something missing from the plethora of languages out there now? What are the newbie's virtues and problems? Simplicity? Completeness? Is the language completely or partially objective? Are there tools to write code with? Plugins for things like Vim? Does it have garbage collection? Compiled? JIT? What's the programming paradigm - is it tightly structured? Are there dependencies? Is this a server side language? How insulated is it from being hacked?

    Many developers are legitimately concerned about the long, lingering Oracle v. Google legal case. Once considered 'fair use', you now might be sued over API 'misuse'. With that in mind, is there anything programmers should be worried about in this new language?

    1. Re:Whip it out by serviscope_minor · · Score: 1

      All good ideas, but too soon. You need to have the meat of something before it's worth setting up the company. In other words, it'll have to start by implementing a basic form of the language. Slow, missing features, weaker library, but the design and initial implemention needs to be there.

      5. YouTube tutorials, starting

      That depends if you want new users or experienced programmers who can help on the project.

      --
      SJW n. One who posts facts.
  29. Steps by AHuxley · · Score: 2

    Start webpage. Something you have total control over.
    Add blog, forum, live chat support. IRC. A gui for browser web chat. Video updates for your site.
    Live webcam chat with a groups of supporters.
    Translations. Have a list of contact details for your site. From security to press, media, general questions, offers of support.

    Someone wants to do an interview at 2 am from their part of the world? Do it. Thank them and be ready for lots of different questions.
    Be ready for video, sound only, the need for lights, a mic and a good background setting on video chat.
    Ensure a good internet connection with another way to connect on the day of the interview.

    Someone sends in a security question. Thank them. Given them a clear time line of how the issue will be responded to quickly. Days, weeks, months.
    Show them the results and ask if they want recognition. Thank them again. Update any blog, security comments as needed over time.

    Set out how the project will be worked on and show progress.
    Update the blog every day. Have more detail over weeks and months. Video clips.

    Keep control over your forum, your blog, your clips. Sites and social media can change their TOS at anytime so social medias offer of "free" and lots of "ads" can change at any time.
    Read all TOS on any hosting and code site and what owners have set out as their politics and conditions when using their site, tools.
    Upload examples, a guide, FAQ and what is supported so people can get an overview. Then how to support the project.

    --
    Domestic spying is now "Benign Information Gathering"
  30. Re:step one by Stephan+Schulz · · Score: 1

    And seriously, TEN YEARS to write a compiler? If he has a grammar (and if he doesn't, he has NOTHING) then just slap it into a parser generator such as Bison, and connect that to the gcc backend, or an existing parse tree interpreter, and you're done. That is a couple of weekends.

    That was my first thought. Especially if the language is wonderful, it should also be small and elegant. Just build a prototype compiler on top of LLVM or the gcc backend, or, if you are lazy like me, compile to C.

    But maybe he really has a wonderful idea that does not map so easily to conventional frameworks - something with lazy evaluations and monads, or something with very powerful build-ins (constraint solving, Gröbner bases, FFT) that needs a lot of library work.

    Of course, my wonderful language (back when I had less knowledge and more illusions) was just C with all the warts fixed. I have since learned that the warts are all there for reasons, and most for good reasons....

    --

    Stephan

  31. You don't, without something that works. by tlambert · · Score: 1

    You don't, without something that works.

    Mozilla was pure mental masterbation for years, until it was possible for someone outside the company to build a working version of a browser.

    Until and unless that happens, you've merely "declared a project", and like most such projects on SourceForge or GitHub -- absolutely no one will give a damn, until you ive them the power to tinker.

    And you will not do that without working code.

    By the way: if you are actually a UNIX/Linux systems programmer... it will take you less than three months in your spare time to get your compiler up and running on LLVM.

  32. Re:step one by LostMyBeaver · · Score: 2

    I was thinking in this direction as well.

    Unlike ShanghaiBill, I write languages often enough to not say things like Bison anymore. Bison and Flex are 1960's to 1970's technologies for compiler design. These days, writing a new compiler is far easier than that.

    Step 1) Parser generator
    Using Antlr which is pretty much one of the most common solutions (though I really don't like Antlr myself) is very easy. You can open Eclipse, setup Antlr and pretty much have a parser up and running very quickly.

    For prototyping a language quickly, using a Packrat parser generator is far quicker, but generally requires building your own AST. Though in modern languages, this is stupid simple. Simply start defining the grammar and add a new abstraction for each type. Then reduce the types as common features become obvious. Expression parsing is generally some of the more difficult tasks you can encounter as they tend to be highly recursive, but it's pretty simple.

    To do a great, job, hand coding a parser is pretty simple these days. While a tokenizer can be a very powerful approach to doing this, generally tokenizing as you parse is really super simple. Same concept as is generally applied to a Packrat, but you just make a class which allows pushing and popping states. Then you make a function to match a regular expression or series of regular expressions. I like to make a solution which takes accepts a list of expressions and lambdas, then given the current state which I'm parsing, I concat all the valid expressions for the state into a single expression with named matching. Then I pass the parser state to the lambda as a parameter. The result is a ridiculously easy parser to write which performs pretty well. It's also very easy to later optimize by caching the compiled expressions.

    A major advantage of the hand coded parser is that it's far easier to add extensive static code analysis to a hand coded parser than most generated ones.

    2) Make a simple tree optimizer architecture

    While tree optimization probably isn't necessary in earlier phases for the purpose of performance, it's extremely useful for reducing more complex states of the tree into more easily compilable branches. For performance, it's really nice to find things like AST states of multiple consecutive if statements against the same variable with the same type and reduce it to a select clause which can be easily optimized.

    3) Produce a backend

    Compiling to C is super easy. C++ is also really super easy. On the other hand, while LLVM IL is somewhat complex for people who don't understand things like startup code and exit code... and things like register allocation can be confusing to many, it's actually pretty easy to generate.

    Compiling to WebAssembly is great option as well.

    These days, I tend to favor compiling to JavaScript. JavaScript is a far better compiler backend than most. It generally produces far better code than even the best C and C++ compilers. This is because C/C++ generates good/great code once. JavaScript JITs however have a modern runtime which constantly optimizes code for the platform it's executing on. It's far more intelligent with regard to SIMD instructions when possible that most other platforms. It's generally truly cross platform as well. If favoring a specific platform such as Qt (which I believe embeds v8), it's quite easy to build GUI extensions. I prefer to compile to JavaScript 5 as it's available everywhere. It's greatest weakness is that it doesn't properly support regular expressions.

    The other beautiful thing about compiling to JavaScript is that massive amount of work has been done to allow easy synchronization for compiling. This is handled well through map files. As such, building a great debugger experience is practically free.

    Using .NET as a back end is absolutely a wonderful experience as well. .NET has excellent extensions for language design. As part of the .NET experience, it's made al

  33. attempt at positive response. by anon+mouse-cow-aard · · Score: 1
    insomnia sucks...

    Get something working (even if it only is 1% of what the real thing is supposed to do.) put it up on github.com. Make sure the build/test environment works on Linux, because that's where likely contributors are. Tell people about it. If it really is a world-changing idea, someone will care, and may contribute.

    I have done a handful of open source projects. I'm convinced some of them are really cool, but they're niche, and it is very rare to get any help. In Startup jargon, they talk about *minimum viable product*. To make something attractive, so others will join, they need to see it as immediately doing something for them. I think you need to get your product to an MVP state before you start trying to get others to help.

    If you cannot get working code on your own, then forget it. No-one will even understand what you project is about. Talking, explaining , etc... is very difficult. Show, don't tell applies in software. Getting *something* working also makes you learn a lot about the idea, and explore it and understand it better yourself.

    Somebody mentioned bison and yacc. Those are tools that date back to the seventies when DSL's (Domain Specific Languages) were fashionable, they are about 90% of what you need to build a compiler. They have been used to build thousands of DSL's and would very likely be good enough to build an initial product, and you will learn a lot. If you still think it is a good idea after building the initial compiler, then great! Another approach would be to build the compiler in a *easy* language like python. This paper: https://legacy.python.org/work... outlines an approach to doing that.

    So those are technical strategies for doing what you want to do. Personally I think inventing a new language is unlikely to be helpful. Programming languages are a means for people to talk to eachother very precisely. They go through exactly the same economic & network effects as human languages, and people are inventing human languages from time to time, and they don't catch on. Examples: Esperanto, or more recently, Toki Pona (https://en.wikipedia.org/wiki/Toki_Pona) proposed in 2001, with 100 fluent speakers in the world! Worse, there are a lot of human languages that are dying off ( https://en.wikipedia.org/wiki/... ) , not necessarily because of any genocide, but instead because the populations are being assimilated into bigger groups. This is just the Network effect (Oscar Meyer effect for North Americans of a certain age.)

    Network effect is huge: people learn programming languages because other people already use them and provide libraries of stuff that is already done. Programming languages was a primary area of research in Computer Science in the 70's & 80's, taught formally at school, and there is a lot of literature and dead languages from that time. That seems to have calmed down a bit in recent decades, and the world seems to be converging a bit. There are still hundreds of reasonably popular (even if only in specific niches) languages and it is hard to imagine what *your* language would bring to the table that would be of sufficient value to overcome the massive network effect of introducing a new one.

    there are explicitly pedagogical languages like Scratch ( https://en.wikipedia.org/wiki/... ) but the problem with pedagogical languages is that any skills the student acquires, they kind of need to start over with a *real language* at some point, so there needs to be a really big payoff to justify the diversion. The top programming languages ( https://www.tiobe.com/tiobe-in... is one indicator ) are Java/C#, C/C++, and Python. Of those three, python is the obvious first choice in terms of ease of gett

  34. Re:step one by TheRaven64 · · Score: 1

    For prototyping a language quickly, using a Packrat parser generator is far quicker, but generally requires building your own AST.

    Pegmatite is designed for rapid prototyping and for teaching (where students are expected to add new language features in a couple of hours. It uses PEGs in an embedded DSL in C++. It doesn't do Packrat optimisation, because that makes it harder to debug (and by the time you need that kind of performance it's probably worth replacing it with a hand-written recursive-descent parser (which also makes helpful error messages easier to write). You can define AST node classes and declaratively associate grammar rules with AST nodes.

    There are a couple of example languages in the same GitHub organisation that are about 1,000 lines of code each for a complete language with an LLVM-based JIT.

    --
    I am TheRaven on Soylent News
  35. Linus? by thegarbz · · Score: 1

    Linus Torvalds was able to leverage the enthusiasm of the Internet to make Linux exist

    No he wasn't. He brought Linux together all on his own without external help. Once he did so the enthusiasm of the internet made Linux popular.

  36. Re: step one by reanjr · · Score: 1

    Not all languages can be parsed with Bison. Not all language features are clearly supported by LLVM. For some, self-hosting is important. Some people want to tweak a few things with their new language. Others want to rethink everything.

  37. 500 out of 500 (just say "I forget to call free") by raymorris · · Score: 3, Informative

    > The static nature of C makes it really slow unless you're writing very static code with very simple data.

    Of the 500 fastest supercomputers in the world, 500 are C-based systems. C is the ONLY language used by super-fast systems.

    >Implementing relocatable memory in C is basically impossible

    Please see - well anything under /usr/lib.

    Otherwise, it sounds like basically you're trying to say "I forget to call free() after I malloc some memory".

  38. Merge Your Efforts by cultibot · · Score: 1

    You can pay people to do something that won't matter in the end, but unpaid volunteers need some more substantial justification for the time and effort they invest. Better than to start a new effort from scratch would be to distill the aspects of this idea that are new and better than existing compilers, and take those to the community surrounding an existing open-source effort, such as http://llvm.org/

  39. Re:step one by maestroX · · Score: 1

    And seriously, TEN YEARS to write a compiler? If he has a grammar (and if he doesn't, he has NOTHING) then just slap it into a parser generator such as Bison, and connect that to the gcc backend, or an existing parse tree interpreter, and you're done. That is a couple of weekends

    Well not really, gcc had this really difficult to access parts of the compiler (I'd prefer ANTLR/llvm also).
    As a retired systems programmer it shouldn't be too hard to regex the tokens, hardcode the expressions/grammar if-then-else way without typechecking and churn out some javascript code.
    Do the trickiest grammar parts first, so you have spare weekends for discovering ye next greatest sorting, compression and encryption algorithms.

  40. Re: step one by david_thornley · · Score: 1

    What sort of reasonably modern languages aren't parsable by Bison? I'd think that a language without a context-free grammar would be likely to be confusing to humans and difficult to write tools for.

    --
    "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  41. The same thing that makes the world go round by The123king · · Score: 1

    Money

    By paying people to develop your compiler, you're taking some of the workload off your back, and putting it on someone elses, in exchange for money. If you employ enough people, and keep the source code proprietary, you could then sell licenses to your compiler and generate a profit.

    Many technology companies use similar tactics to generate income.

    --
    If you gave me a choice between a printer and a giraffe with explosive diarrhoea, i'll get my ladder and my raincoat
  42. Re:500 out of 500 (just say "I forget to call free by LostMyBeaver · · Score: 1

    The vast majority of super computers are distributing tasks through a scheduler which happens to be written in C. The code they distribute is most often developed in Matlab or similar languages... which are hogs and run so amazingly inefficiently, They generally work on extremely static data sets as well. Super computers are best suited for consuming data, not producing it. The key exception is the LHC.

    Two years ago, I saved an oil exploration company $4 million a year in super computer rentals by introducing their scientists to Intel's VTune. Now, code which used to require time on Top500 computers to calculate runs fairly well on 3 rack servers with 4 GPUs each. Never ever ever use super computers as a method of describing efficiency.

    If you want to test a small scale example of this, get your hands on Cisco Prime. A function of Prime is to consume data from spread spectrum radio analyzers for many purposes ranging from adjusting transmitter power levels for wireless networking to performing rogue device detection ... you know... all that nifty math stuff for radio. Cisco requires 16 dedicated Xeon CPU cores and 24 gigs of RAM to run this software. And as soon as you do that it becomes a dog with flees. If you ignore Cisco's hardware requirements and use a $500 computer containing a $69 NVidia GPU and slipstream the NVidia drivers into the Linux distribution, the Matlab code will use the GPU and run 1000 times faster than on 16 dedicated Xeon cores. On the other hand, if they were to actually tune and profile their Matlab code, it could probably run 100,000 times faster as the Matlab code they're running is actually incredibly slow.

    What they're doing is basically a super computing task. And the math they're performing is typically super computing math. It's super-inefficient and even after a so called super computing expert analyzes their code and attempts to make optimizations, there's very little that can be done for most code like this. You'd have to rewrite it for there to be any hope of it not sucking and since the code is often highly convoluted crap, it simply is generally impossible.

    So we use super computers that generally run massive schedulers written in C that should have been written in a scripting language but someone was an idiot. The we run code which probably should have been rewritten to work on a laptop GPU but instead will burn computing time at $25,000 or more an hour. We do that because the code can run on the super computer now, rewriting for a laptop GPU will set things back a year.

    Finally, don't forget that 99% of the C code which is run on super computers is compiled to C from other languages. This is done because you would never write that kind of code in C. The other reason is that you can't really easily distribute the programming language you coded in to all the systems. Oh... and to make your code work on x86, Cuda, OpenCL, whatever else... you don't hand code that. You use a high level language like Matlab which will compile your code into code that can run on all these things.

    Relocatable memory has absolutely nothing to do with malloc and free. It's the principle that memory can be relocated. So, as opposed to using a pointer to a fixed memory location, you would use a pointer to a pointer and access the memory through helper functions.

    The purpose of this is that when you're performing a massive amount of allocation and frees, there is a tremendous amount of memory fragmentation that occurs. So, if a web browser for example which is very dynamic in nature will end up with massive amounts of wasted memory because it is nearly impossible to defragment the memory.

    Solving this problem in C is definitely possible, but the static nature of C makes it very very difficult. As such most dynamic applications written in C are hogs. It looks like "wow I'm hardly using any memory" but the entire system is suffering because C is so poorly suited for memory management.

    Using proper modern languages, things like movi

  43. Re: step one by reanjr · · Score: 1

    Neither C nor C++ has a context free grammar. Perhaps those aren't "modern" enough, but they are at least important enough to think about emulating in some cases. Python does not have a context free grammar either, but I think it's still parseable with bison.

    Natural language programming is another area that gets into (infinitely) more complicated language parsing designs.

  44. This is a very hard problem. by Qwertie · · Score: 1

    I have the same problem as you with my ideas for "Loyc" projects at http://loyc.net/ - they gather very little interest. As a consequence, I've lost enthusiasm for my projects and subsequently they've had little progress. I suspect the problem is that people don't want to really look at or help with a project until it is already fairly mature. It could also be that everybody's too busy trying to make a living. But perhaps I haven't marketed my ideas well enough or done a good enough job explaining what I want to accomplish.

    People have good reasons - other than learning curve - not to learn your new programming language:

    - There are already lots of good languages out there. I've seen lots of language designs that failed to even attempt to answer a basic question, "what advantages does my language provide that NONE of the existing languages do?" I think that's because most new language designs actually DON'T provide anything that hasn't already been done pretty well by existing (but often unpopular) languages. Make sure you've looked at other less-popular languages like Nim, Ceylon, D, Rust, etc. to see if they can't already do what you want.

    - New languages have lousy tools. Lots of developers expect IDE autocompletion features, a package manager, a debugger, a way to target Android/iOS, a way to target web browsers, and of course syntax highlighting.

    - If they write code in your new language, it won't interoperate with other languages. You could make it a .NET language or JVM language so it can interoperate with other .NET languages and JVM languages (and you get multiplatform support for free), but both of these options (especially JVM) substantially constrain the design of your language - your language won't be capable of various low-level features that .NET and JVM cannot do. You could (and should) support interop with C, but C libraries tend to be very clunky to use (e.g. memory management is always a pain in the ass.) I'd say the .NET runtime has stagnated for quite a few years but it looks like they're finally adding valuable new features, e.g. a feature traditionally known as slices, which in .NET is called Span.

    Without interoperability, your language will be extremely limited since it won't be able to take advantage of existing code libraries, and therefore very few people will want to use it even if the language design is fantastic. In Loyc I want interoperability to be a core focus (though again, due to lack of outside interest I've made little progress).