[HN Gopher] Why aren't there more programming-language startups?
___________________________________________________________________
Why aren't there more programming-language startups?
Author : mpweiher
Score : 65 points
Date : 2021-07-21 18:03 UTC (4 hours ago)
(HTM) web link (www.akitasoftware.com)
(TXT) w3m dump (www.akitasoftware.com)
| spamizbad wrote:
| The most successful programming language startup (Microsoft)
| ultimately had to pivot to operating systems to go public and
| then pivot _again_ to office suites and cloud computing to stay
| relevant.
| DylanDmitri wrote:
| More recently they wanted to monetize C#, but found it best to
| make the language itself free and open source while monetizing
| through complementary products.
| nightski wrote:
| When did they ever want to monetize C#? That is pure FUD.
| It's been an ecma standard from the start with multiple
| compiler implementations including Mono since very early
| 2000s.
| andi999 wrote:
| What are complementary products for c#?
| [deleted]
| nwatson wrote:
| Azure, Windows Server, SQL Server, Exchange, MS office,
| Dynamics, anything else in the enterprise suite where C# is
| a good integrator.
| spamizbad wrote:
| I'm sure they still make good money from MSDN subscriptions
| but the value of that is deeply tied in with Microsoft's own
| platform (Windows, SQL Server, Azure, etc).
| jeremycarter wrote:
| Where is the evidence to support this? Utter fabrication.
| tester756 wrote:
| >More recently they wanted to monetize C#,
|
| what? src?
| JohnFen wrote:
| I agree with jcrammer in that the question being posed isn't
| really the one the article seems to be discussing. I read the
| article as discussing "why aren't there more new programming
| languages"? So I'll comment on that one instead.
|
| As an aside, I've been a professional developer for several
| decades now, and that's a question that I've heard for my entire
| career.
|
| I think the answer is a combination of things that are
| impediments to the adoption of new languages of any sort, no
| matter how much of an improvement they may technically be
|
| 1) If there isn't an accessible supply of developers who know the
| language, using the language becomes risky as a business
| decision.
|
| 2) Related to #1, using a new language is placing a bet: once
| you've put a lot of time, money, and sweat into developing a
| codebase in a particular language, if that language falls out of
| fashion then you're stuck with a codebase in a language that will
| lack support and a ready supply of developers who know it and are
| willing to work in it.
|
| 3) Career-minded developers will tend to prefer to develop skills
| that are likely to be in demand with a wider array of potential
| employers. Much like the bet I talked about above (#2), working
| in a new language is also a bet being placed by the dev.
|
| 4) New languages tend to have immature toolschains. Using them
| can result in decreased production (and possibly decreased
| quality) as a result. This problem goes away should the language
| see widespread adoption, but that takes a while and may not
| happen.
|
| There's a reason that the most-used (as opposed to most popular)
| languages tend to be ones that have been around for a while.
| They're safer (from a business point of view).
|
| I've also noticed that the newer languages that become popular
| tend to grow out of hobbyist use. Devs learn and use them for fun
| in their off time. Some become proficient in them and advocate
| them to other devs. Once this hobbyist community reaches a
| critical mass, then companies will begin to entertain using the
| language, but not before.
| avrionov wrote:
| The article is a little mis-titled. It asks the question about
| the Programming languages, but it goes into discussion
| development tools. This the correct framing of the problem, the
| language itself is very hard sell. It requires an an environment
| to flourish: libraries, build tools, etc.
|
| I'm very excited about the variety of languages which are being
| actively developed right now. There are 2 major open source
| projects which are helping quite a bit for the new languages: -
| Visual Studio Code (Eclipse used to be the choice in the past).
| Every language can get high quality IDE with a simple
| integration. - clang & llvm - high quality back-end and common
| code generation tools.
|
| The developer tools market is not going to be extremely big. In
| most mature companies the R&D costs are up to 15% of the revenue
| and the dev tools is fraction of that.
| InvisibleCities wrote:
| Because programming languages are a public good, and public goods
| are fundamentally incompatible with a profit motive. A
| "programming language startup" would be like an "anti-poverty
| startup" or "social justice startup" - either an edifice doomed
| to fail because of its inherent contradictions, or a front for
| lies and grifting.
| samatman wrote:
| This premise can be trivially disproven with one citation, so
| I'll choose Clojure and Cognitect.
|
| Ok, not _fundamentally_ incompatible, right?
| lmeyerov wrote:
| Cognitect was a successful consulting services startup that
| didn't build a scalable software product/service, right?
|
| I'm not sure why they would have sold if they ever figured
| out how to make a software part of the clojure ecosystem
| sustainable & growable revenue source, e.g., hosting.
|
| In contrast, Julia's recent fundraise is on a successful
| science tool that happens to be written in Julie, and a hope
| that hosted Julie might one day pay the bills. But not proven
| yet. NPM & dockerhub showed repo hosting is tough to succeed
| on even with wide use, though Anaconda shows promise when
| mixed with consulting revenue.
|
| Jean's article also toes around developers not always being
| the buyer, so requiring a model more like Twilio, where they
| are presales/marketing for some other customer. That kind of
| misalignment adds another level of pain.
| v3np wrote:
| A counter-example: https://daml.com/
|
| Daml is essentially a smart-contract language using Haskell
| syntax with built-in primitives for privacy & authorization
| (e.g., so you don't have to either make your whole ledger public
| or private)
|
| Worth checking out if you're into DLT & PLs! :)
|
| Disclaimer: I work for the company developing this.
| CalChris wrote:
| I like Grady Booch's explanation from the Twitter thread:
| Rational Software was this: founded in 1982, acquired by IBM in
| 2003 (they outbid Microsoft, who were also interested in
| acquiring us). They were a number of dev tool
| companies in that time, but no more: open source makes the
| economics of this a tough sell these days.
| michaelbrave wrote:
| A lot of my friends work at companies with legacy code, a lot of
| which have libraries that they bought where the company isn't
| even around anymore and it was locked on to a specific system by
| license, they can't transfer it, can't fix it, can't update it.
|
| I won't use a language that isn't open source, I don't trust
| companies enough, there is a chance they could die, revoke a
| license or do some other stupid thing that makes it unreliable in
| the future.
| munificent wrote:
| It's a truism that programmers won't use non-free programming
| languages, but I don't think anyone in this thread has talked
| about _why_.
|
| I think a key part is that investment in a language goes both
| directions between programmer and language author. When someone
| learns a language, they are spending a lot of time and effort to
| load that language into their head and build expertise in it.
| That effort amortizes out over the amount of useful software they
| are able to write in that language in return. When the language
| is paid and where users have no control over the cost, they can
| end up in a situation where they are unable to extract value from
| what they've already learned if the language gets too expensive.
|
| It's sort of like asking users to turn a corner of their brain
| into farmland but then giving the compiler authors the key to the
| padlock on the fence. Users don't want to give financial control
| over a part of their own headspace to someone else.
|
| Free programming languages ensure that the user can always have
| access to the value of their own expertise in the language.
| mojuba wrote:
| That's a very interesting thought and it seems to answer the
| question in the title (which the linked article doesn't).
|
| In theory though there are certain business opportunities in
| this space that haven't been explored yet, it seems.
|
| For example, a faster and better compiler for a popular
| language that itself is slow, might get some traction.
| Personally I would pay for a Swift compiler that doesn't take
| _seconds_ to compile a single long-ish expression with floating
| point arithmetic, or doesn 't take tens of minutes to fully
| build a project that isn't even that big. Similarly I'd pay for
| a replacement for Xcode that doesn't have bugs in every single
| feature it implements. As an iOS developer I'm honestly very
| tired of and fed up with both Swift's slowness and Xcode's
| bugginess. There has to be some competition here too, already.
|
| In other words, competition is what the PL industry is lacking,
| I think. But not among the languages themselves as much as
| among the compilers (and possibly the rest of the tooling and
| environments).
|
| I don't know how we ended up in a world where there's only one
| compiler per each newly created language. I'm not sure this is
| normal or it's the way it should be.
| sanxiyn wrote:
| > For example, a faster and better compiler for a popular
| language that itself is slow, might get some traction.
|
| I used to think this, but now I am skeptical, because of
| zapcc. zapcc was almost exactly this: a faster compiler for
| C++, first propreitary, now open source because it failed.
| Still no traction.
| paulgb wrote:
| > It's sort of like asking users to turn a corner of their
| brain into farmland but then giving the compiler authors the
| key to the padlock on the fence. Users don't want to give
| financial control over a part of their own headspace to someone
| else.
|
| Well put. I think this is why the Google/Oracle court battle
| was so contentious to a lot of programmers. It wasn't just that
| people hate Oracle (sure, that too), but also that it was about
| Oracle trying to claim a monopoly on whatever piece of our
| brains is dedicated to our knowledge of Java.
| [deleted]
| PaulHoule wrote:
| I have been thinking about the topic for a while and the article
| seems a bit wrongheaded to me. (e.g. you just can't save time by
| deliberately making tools that aren't 100% correct as much as
| everyone wishes they could.)
|
| For instance, "parser generators" like yacc, bison and all the
| rest are absolutely awful. One feature they miss is that you
| should be able to make a small revision to a grammar with a small
| code patch. (Say you want to add an "unless(x)" statement to Java
| that is equivalent to if(!x)" - ought to be 50 lines of code not
| counting the POM file.)
|
| I think a better parser generator could open up "compiler
| programming" and "meta programming" to a wider audience and get
| LISP fanatics into the 21st century, but it never happens.
| Anybody who understands the problem enough to solve the problem
| will settle for a half-baked answer; the labor input to go from
| "the author can use it" to "revolutionary new parser generator"
| is a factor of 10x and there is some risk that people still won't
| get it.
|
| Programming the AVR-8 Arduino it's hard to miss the conclusion
| that "C sucks" but anything really better (say Supercharged
| Pascal or a Miracle Macro Assembler) would take a huge amount of
| fit and finish work to make it something that would really beat
| C. For pedagogical purposes you can argue that C rots the mind
| like BASIC but you can't argue that learning C is a waste of
| time.
|
| To make a profitable business out of any of the above seems
| almost impossible.
| Ar-Curunir wrote:
| I don't think parsing is the hard part of designing a compiler
| any more
| PaulHoule wrote:
| It's not the hard part of "designing a compiler" but who
| wants to "design a compiler?"
|
| In ordinary software people spend most of their time
| modifying existing code. I wouldn't want to reinvent "javac"
| or "cpython" but adding a new feature to a compiler like that
| should be easy.
|
| Alternately there are a number of "compiler-technology based
| tools" that we don't have. Instead we get problems like
|
| https://www.liquibase.org/
|
| which defines a whole new XML-based language to manage
| database changes. That's like jumping from the frying pan to
| the fire since you're still going to have to understand your
| RDBMS, how to write SQL for it, what the non-standard
| features are in your database, etc.
|
| A sane tool like that would use an extensible parser
| generator to easily support the variant syntaxes of different
| SQL dialects and would be able to parse and unparse SQL or a
| variant of SQL to define change sets.
|
| (speaking of which... shouldn't a compiler generator
| automatically make something that can reverse the AST back to
| source code? how about round-tripping source code comments,
| formatting and all like some CASE tools did in the 1990s?)
|
| A while back I had the problem that arangodb scrambled the
| order of columns in JSON result sets and wrote something that
| parsed the AQL, figured out what the order of the columns
| was, and turned the result sets into nice pandas frames.
|
| If "writing compilers" was easier people would write
| "compilers" that do things other than compiling to machine
| code.
| calebh wrote:
| I've worked in a number of spaces that you mentioned. Parser
| generators are awful, which is why my preferred parser
| technology are parser combinators. They occupy a nice space
| between parser generators and handwritten recursive descent
| parsers.
|
| Meta programming is an excellent target, but it usually needs
| to be directly baked into the language. The closest system I've
| seen to a nice language agnostic close to meta programming
| system is Jetbrains MPS and Spoofax Language Workbench. Last
| time I checked, MPS is mostly dead and Spoofax is only used my
| programming language researchers.
|
| For the Arduino programming stuff, I currently maintain a
| domain specific functional reactive programming language for
| Arduinos called Juniper: https://www.juniper-lang.org/
|
| However the intersection between people who do Arduino
| programming and functional programmers is quite small. Also my
| interest has waned on and off over the years which means there
| have been long gaps between releases. I just work on it for fun
| mostly.
| blippage wrote:
| > Programming the AVR-8 Arduino it's hard to miss the
| conclusion that "C sucks" but anything really better (say
| Supercharged Pascal or a Miracle Macro Assembler)
|
| I did see an Ada compiler for the AVR recently (I'm not an Ada
| programmer). It seemed unpolished, and not really an
| advancement on C.
|
| I think one problem with embedded work is that you either stick
| to the low-level, in which case you have no advantage over C,
| or you go for high-level, in which case you have convenience
| but lose flexibility.
|
| In terms of meta programming, Val Schorre has an interesting
| idea with META-II. Both Alan Kay and Joe Armstrong spoke highly
| of it.The compiler has its own assembly language. I had this
| goofy idea of writing a Basic-like language that replaced the
| assembly. So you'd have a language that was both high-level
| Basic and a compiler. It would embrace the GOTO, because META-
| II also generates GOTOs, and GOTOs are a natural fit for CPS
| (Continuation Passing Style) used by many compilers.
| PaulHoule wrote:
| Personally I find bit-twiddling in C to be painful compared
| to bit twiddling in assembly.
|
| For my Arduino projects in particular I never make recursive
| function calls, and would be happy to statically allocate
| everything in RAM. The stack-oriented activation records in
| C, calling conventions, return values, are more a problem
| than a solution.
| calebh wrote:
| For call graphs without cycles it should be possible to run
| static analysis to determine the maximum amount of memory
| taken by your program at any point, assuming you don't use
| things like malloc or alloca or dynamically sized arrays.
| drannex wrote:
| > but anything really better (say Supercharged Pascal or a
| Miracle Macro Assembler) would take a huge amount of fit and
| finish work to make it something that would really beat C.
|
| Zig is trying to work in this space, and they seem to be
| getting rather close to the ideal.
| rightbyte wrote:
| > For instance, "parser generators" like yacc, bison and all
| the rest are absolutely awful. One feature they miss is that
| you should be able to make a small revision to a grammar with a
| small code patch. (Say you want to add an "unless(x)" statement
| to Java that is equivalent to if(!x)" - ought to be 50 lines of
| code not counting the POM file.)
|
| You could do that. Add "unless" to the Flex file and hack the
| Bison file to interprete 'unless->expression' as an
| 'if->negation->expression)' when pushing to the abstract syntax
| tree. You can probably copy paste from the other rules for the
| hypotetical Flex/Bison Java compiler.
| flashgordon wrote:
| Actually do you mind expanding on the quality of yacc, bison
| being awful. I dont mean that as passive "oh yeah?" line to
| "trap" you. Language front-ends (and their tooling) is
| something I am pretty passionate about and having developed
| parser generators in the past (and working on something now) I
| just wanted to explore specifics that make yacc, bison unweildy
| for others.
|
| Just to start off - I still find their debugging or their (lack
| of) ability to reason a huge barrier to wannabe language
| developers. But I am still unable to put this in concrete
| terms. My last few months has been immersed in reading a ton of
| papers and I still see the papers use bison as the staging
| ground for most new ideas (menhir these days seem to be gaining
| popularity) so curious what is keeping yacc/bison in their
| throne position?
| PaulHoule wrote:
| For one thing the callback-based interface in yacc is
| unergonomic.
|
| In a language like C# or Python you usually want to get an
| object tree for the AST and you shouldn't have to write any
| code to get that. It should come "for free" with the grammar.
|
| Another missing capability that people don't know they are
| missing is the ability to "unparse" the AST back to text.
| This is valuable when you want to write a code transformer:
| for instance in query languages like SQL there is a lot of
| value in doing a transformation on the query and then writing
| it back to SQL. You should be able to transform the AST and
| not have to write a line of code to transform it.
|
| Another problem is composability of grammars. If you want to
| support SQLLite, Microsoft SQL Server and Oracle SQL dialects
| you should have a base SQL grammar and extended grammars that
| inherit from the base.
|
| All of these capabilities are so beyond the pale of what
| parser generator "insiders" are used to that it's a very hard
| conversation to communicate that these capabilities are both
| possible and useful.
| metadata wrote:
| Your thinking very closely reflects mine. I actually did
| build a C# parser generator producing strongly typed AST
| from base ANSI grammar and inherited Oracle, SQL Server,
| MySQL, and Postgres grammars. We are using it in our
| database migration products and will soon use it for
| Resharper style intelligence in a very lightweight and fast
| database manager. It never occurred to me to publish the
| parser generator, though. It's our secret sauce.
| cellularmitosis wrote:
| The high barrier to entry for creating dev tools is truly a
| shame, and something I think about a lot.
| TuringTest wrote:
| The mental model distance between dev tools and user tools is
| simply too large. Dev tools are still too anchored in the
| 50's model of source-code >> compilation >> runtime code,
| when consumer products have a much more healthy mixture of
| active content and tool palletes working on the content.
| Heck, even the guy in the article asks about "Programming
| Languages Startups" when he means "Integrated development
| startups".
|
| This difference is shrinking in the web, both client
| (DevTools run like an app inside the browser, with live
| changes to the code reflected instantly in the page) and the
| cloud (the entry point interface is a collection of
| collections, where you can inspect and operate on any
| component running in the system, and even create some kinds
| of workflows in the live environment).
|
| But the lowest level for designing components relies on
| specifying a fully formed program in formal code, and having
| to run a build-deploy-test cycle without errors before seeing
| whether it works, instead of having code and data run side by
| side to see how the code behaves.
|
| I put my hopes in online notebooks, but these are used mainly
| for data analysis, and "true developers" seem determined to
| ignore them.
| PaulHoule wrote:
| The gap from an "online notebook" to "here's the script to
| run the monthly report" or "here's the model complete with
| training and inference that anybody can retrain" is wide.
|
| Yet it's the difference between a data scientist making an
| occasional report to putting their expertise on wheels that
| makes it worth paying for.
| TuringTest wrote:
| Notebooks don't need to be online. You can run a local
| notebook same way as you run a local IDE.
|
| The most significant difference is that the notebook
| always has runtime information about how the available
| information is being processed, while the IDE only has
| this information available while it's in debug mode. The
| first model provides much more information about the
| system behaviour, easier to access.
| JohnFen wrote:
| > I put my hopes in online notebooks, but these are used
| mainly for data analysis, and "true developers" seem
| determined to ignore them.
|
| This is merely my own personal preference, not an assertion
| that my stance is correct or common.
|
| For development, it's important to me that I can put the
| toolchain into version control along with the code. This
| ensures that I can check out a build that is years old and
| be able to build it without issue.
|
| SaaS solutions break this for me, so I avoid them to the
| greatest extent that I can. If it's cloudy, then it can
| change without warning or recourse. That's a problem.
|
| For that reason, I would never seriously entertain using
| something like a netbook for development.
| TuringTest wrote:
| You can use toolchains with notebook software, provided
|
| a) the notebook has an internal text representation that
| can be version-controlled, and
|
| b) the notebook follows a spreadsheet-loke paradigm with
| incremental non-mutable data structures, so that all
| state is represented consistently at all times (no
| dependence on what order you've run the cells in the
| current session).
| Ar-Curunir wrote:
| "The guy in the article" is not a guy.
| TuringTest wrote:
| I stand corrected.
| brundolf wrote:
| I had the idea a while back to do a parser-generator in the
| form of Rust macros, which would mean a) you don't have to
| source-control a giant pile of generated files, and b) you get
| real-time editor integration without a separate "generate"
| step. I got out of my depth trying to get the actual macros to
| process the BNF (it gets very meta because Rust's declarative
| macros are themselves written in a very BNF-like syntax), but I
| still think this would be possible and pretty cool
| s17n wrote:
| "you just can't save time by deliberately making tools that
| aren't 100% correct as much as everyone wishes they could."
|
| The point was about application development - you can save time
| by making applications that aren't 100% correct. In most
| software, any bug is OK as long as it happens a small enough
| percentage of the time.
| 908B64B197 wrote:
| > For pedagogical purposes you can argue that C rots the mind
| like BASIC but you can't argue that learning C is a waste of
| time.
|
| That's a strong statement.
|
| C's biggest flaw is that it lies about the underlying memory,
| but it's a small language that's especially suited to be easy
| to port.
| PaulHoule wrote:
| If you are exposed to too much C you can't see the C-thulhu.
|
| Undefined behavior is normal. The whole relationship between
| .h and .c files is sick. How you use the "extern" keyword is
| arbitrary. strcpy is Turing complete. It took a while for
| people to realize templates are Turing omplete. I'm not sure
| where the grammar fits in the Chomksy Hierarchy since you
| have to look at the symbol table to parse it...
|
| Good C looks like poetry, but beginning programmers shouldn't
| be subjected to any of it. I certainly hate cleaning up the
| mess!
|
| ALGOL, PL/I and similar languages put a lot of work into
| specifications but nobody really knew how to write a
| specification that could be implemented back then. C was an
| early attempt at specification + implementation that was
| "minimum viable" (almost?) and ready in time to be the bridge
| between microcomputers and minicomputers.
|
| Probably the best idea in C was that you didn't have to
| agonize over I/O in the language specification but you could
| just leave it to the stdlib.
| jcranmer wrote:
| First off, this article isn't actually answering the strawman
| question it looks like its asking. I think most people who don't
| work in the space would assume the question means "why aren't
| there people selling new languages/compilers?" That's a strawman
| question with a trivial answer, though--free compilers have been
| the de facto standard for decades [1], so if all you have is a
| new compiler or a new programming language, you're going to make
| only a pittance on it directly.
|
| The _actual_ question is why are there so few startups for people
| who work on PL technologies--which isn 't limited to compilers or
| programming languages, but includes things like IDEs, debuggers,
| static analyzers [2]. For example, Coverity--a decently well-
| known paid static analyzer--is kind of the best model of what
| you'd expect to see more of here. So it is somewhat more
| interesting to ask why this tool space isn't particularly well-
| served as a market.
|
| [1] The biggest exception to the rule is custom hardware
| (particularly embedded, but this also holds true for mainframe
| and HPC systems), where custom compilers come for the ride. But
| that would be a hardware startup, not a PL startup, so it doesn't
| really count.
|
| [2] I tend to lump in decompilers into the formal
| methods/PL/compilers/software engineering/computer architecture
| spectrum, mainly being a low-level compiler developer myself, but
| I suspect most people would consider reverse engineering tools to
| be a security side of things rather than a PL side things. And
| decompilers are certainly another noticeable successful paid-
| software niche, with the very expensive IDA Pro still remaining
| more or less the industry standard.
| skmurphy wrote:
| This is a good analysis. The core question is, "Why aren't more
| startups are working on programmer productivity."
|
| My early experience was in system design for board level and
| chip level systems (e.g. ASICs, FPGAs, SOCs) where there is
| considerable investment in tools ("electronic design
| automation" because we had some clear metrics for developer
| productivity.
|
| My simple answer is there are multiple reasons:
|
| + The industry has been very well served by open source tools.
|
| + Outsource development and test firms tend to bill by the hour
| not the result, cutting hours lowers their revenue.
|
| + Coaches tend to focus on methodology and process results, not
| programmer productivity.
|
| + Managers of the programming / development function don't
| appear to devote cycles to determining where investment in
| commercial tools would pay off. There are exceptions.
|
| + First level managers tend to measure success by headcount,
| mirroring the outsource development and test firms, and not
| results.
|
| ---
|
| I think there are significant opportunities for startups
| developing productivity tools but they are in niche markets
| that complement existing open source where development teams
| are paid for or rewarded on results not hours.
| AceJohnny2 wrote:
| > _[1] The biggest exception to the rule is custom hardware
| (particularly embedded, but this also holds true for mainframe
| and HPC systems), where custom compilers come for the ride._
|
| This is exactly what RISC-V was created to address. People here
| get excited about running Linux on it, but really the goal is
| to have a flexible, extensible ISA that can be used from
| microcontrollers [1] to DSPs, GPUs, & TPUs. Full-on Application
| Processors, with their FPUs, MMU & Cache, are only a small part
| of the design space of RISC-V.
|
| The shared ISA means the rest of the stack could share and
| leverage tools. Any day now ;)
|
| [1] https://www.espressif.com/en/news/ESP32_C3
| AceJohnny2 wrote:
| For this information, I recommend viewing Dave Patterson's
| "50 years of Computer Architecture" talk:
|
| https://www.youtube.com/watch?v=HnniEPtNs-4
|
| Dave Patterson is one of the creators of RISC-V, and his
| credentials include pioneering RISC, the original concept.
|
| https://en.wikipedia.org/wiki/David_Patterson_(computer_scie.
| ..
| brundolf wrote:
| Here's my theory: tools for developers are one of the most
| obvious and satisfying kinds of projects you can work on, and
| immediately benefit the person working on them, which means the
| free/open-source options are exceptionally competitive
| (compared with the free/open-source options in other
| categories)
|
| Though there is probably also a "commoditize your complement"
| effect going on from big tech. Just look at VSCode: it's
| incredible - Microsoft could definitely charge for it - but
| they aren't even interested in doing that.
| q-big wrote:
| > it's incredible - Microsoft could definitely charge for it
| - but they aren't even interested in doing that.
|
| Because the telemetry data is worth more to them.
| phillipcarter wrote:
| Not really. I mean, the telemetry data is important to the
| business, but it ain't the reason why VSCode exists.
|
| A much bigger value is that VSCode brought Microsoft into
| the consciousness of developers who would have otherwise
| never thought of using a Microsoft product for anything.
| It's been so successful that there are even classes of
| developers who think that "Visual Studio" refers to VSCode,
| not big-poppa-windows-application Visual Studio.
|
| Source: I worked in the dev tools business at Microsoft for
| the past half-decade.
| 0b01 wrote:
| What data telemetry does vscode collect? And how would that
| be useful?
| amelius wrote:
| My theory: no sane programmer wants to be locked-in by the
| vendor of a programming language.
|
| Hence, all successful programming languages are open and free.
| lalaithion wrote:
| Selling static analyzers are hard. Your customer either has a
| bunch of code, none of which was written with the static
| analyzer in mind, and so they have to spend a bunch of time
| fixing spurious errors and warnings, or they have no code, in
| which case they probably also have no money to pay you with.
| NordSteve wrote:
| I've implemented static analyzers in several codebases, and
| every time it's paid off in finding multiple "must fix" bugs.
| acdha wrote:
| > so they have to spend a bunch of time fixing spurious
| errors and warnings
|
| It's rare for a tool to be so shoddy that this is all you
| get. From what I've seen, you'll get three categories of
| report: valid bugs, valid bugs which the developers insist
| are false positives until forced to do in-depth analysis, and
| actual false-positives. The exact ratios vary depending on
| the tool in question but generally I've seen the first two
| categories be a good bit larger than the third.
| colinmhayes wrote:
| My last job was a fortune 500 that decided to start using a
| static analyzer on a 20 year old project. Thousands of
| false positives and less than ten true positives after
| hundreds of hours were spent going through it. Now the
| codebase was definitely a piece of work which is why there
| were so many false positives, but there were plenty of "the
| static analyzer is horrible" false positives too.
| zwieback wrote:
| Coverity is what I was thinking of when I read the article,
| also Resharper. Since I work at megacorp I have access to
| licenses but I think the problem is that running these tools
| effectively adds a lot of overhead. We programmers are a
| jittery bunch so planning ahead and integrating these tools and
| then spending the time is hard.
|
| Back when I started my career almost nothing was free. At the
| time I worked at a startup and we were always drooling over the
| stuff in "Programer's Paradise". We did pay for a few crucial
| tools but couldn't afford many. Times have changed a lot since
| then and the fact that high-quality compilers and IDEs are
| effectively free has raised the bar for paid products
| substantially.
| majormajor wrote:
| Is the answer "because tools for themselves were one of the
| first things developers made"? That's like a forty year old
| market that's already gone through consolidation and
| commoditization.
|
| The author talks about how a lot of the tools currently being
| pitched are not that useful day to day - the static analyzer,
| say, that shows you the ten thousand things you could improve
| but never actually will. Lots of devs out there using print
| statements instead of proper debuggers, so even the existing
| tools often offer far more than they think they need to learn!
|
| From there, my guess would be that the space of _truly useful_
| groundbreaking tools that wouldn 't be just competing with a
| good-enough free one or an established incumbent is pretty well
| explored. This isn't as true for new areas - Kubernetes
| management interfaces tend to majorly suck, say, especially if
| you aren't a keyboard fiend who's going to get the hang of k9s
| quickly - but new areas are also niches that could be risky to
| try to build a company in. And probably also still suffers from
| the "don't know what I don't know" issue.
|
| "Why aren't developers more interested in tools" is an
| interesting resulting question, to me, then. I think it
| probably has to do with the business-driven focus on building
| new systems and new features at high speed. We aren't building
| code to last for more than a few years, in many cases, so how
| deep is it justifiable to go on a particular block of it?
| [deleted]
| darig wrote:
| I made a brilliant programming-language startup. HN banned me.
| snicker7 wrote:
| Proprietary languages work when they fill a niche. I work with
| the Q/K programming language. It's closed source and, from what I
| understand, has a significant licensing fee. But it is a language
| designed specifically to power trading systems (via the KDB+
| platform/ecosystem). It fills a niche well, and is popular in the
| industry.
| user3939382 wrote:
| I've watched what Rich Hickey has gone through with Clojure and
| Cognitect. I think he did a great job there, but I wouldn't say I
| envy the experience he had getting Clojure this far.
| jbverschoor wrote:
| Developers don't pay for languages.
|
| Most don't pay for tooling.
|
| Sometimes they do, and they get bitten by it. So never again.
| mastrsushi wrote:
| A successful programming language is rarely ever something that
| stands on its own. It's usually the byproduct of a corporation or
| some sort of organized committee. It gains relevance through a
| growing community or standardized through some sort of committee.
|
| To answer the question shortly, programming languages aren't very
| profitable. There are so many of them in competition with each
| other and so few that companies can adopt and base their
| recruitment around.
|
| Tech startups usually thrive from apps, services, or valuable
| technologies. Not yet another programming language.
| feifan wrote:
| My personal answer to the titular question is something like
| "there's only so much you can do with our predominant programming
| paradigm (i.e. plain-text)". Programming languages specifically
| can only make incremental improvements and/or tradeoffs in that
| medium.
|
| Tools like IDEs, debuggers, visualizers, etc are more
| interesting, but I think their effectiveness is also limited (and
| creativity constrained) by having to work in a plain-text world.
|
| Moving beyond plain-text is mostly a social dynamics/network
| effects problem, and I wouldn't be surprised if the intersection
| between people who are good at figuring out that distribution x
| people are who are deeply interested in how programming happens
| is actually quite small.
| sanxiyn wrote:
| This is why I am so hopeful for Pernosco, a better debugger
| with better interface.
|
| https://pernos.co/
| mikewarot wrote:
| Here's my particular story, but I'm sure there are many other
| people who were burned in ways that are similar.
|
| I used to pay for a programming language, Turbo Pascal, which
| then became Delphi. Then Borland went crazy and started pushing
| C++, and raising the prices as their focus was lost. Eventually
| they were sold, and the prices went up, and up.
|
| Never again will I be locked into a vendor with a profit motive.
| nindalf wrote:
| There aren't more startups creating languages because it's hard
| to go up against established incumbents who give away their
| product for free. Python, Go, JavaScript, Rust and most other
| mainstream languages thrive on this model. All of them bend over
| backwards to make it easier for developers to join the ecosystem.
| Free tools, free learning materials, easy installation, gentle
| learning curve (as gentle as possible). More developers leads to
| a flywheel effect of more libraries, more teams taking advantage
| of the rich ecosystem, more job opportunities cropping up and
| therefore more developers flocking to the language.
|
| If you have a "pop out the credit card" moment at any point you
| slow adoption and end up with a smaller, poorer ecosystem that
| finds it hard to compete with the Pythons and Gos.
|
| But if your language is targeting a niche where no established
| FOSS language exists, then a startup would work. Create a
| language, give it away for free (MIT or Apache ideally), then
| charge for creating/maintaining niche libraries or other
| consulting. This is the model chosen by Julia
| (https://news.ycombinator.com/item?id=9516298). One of their main
| competitors is a paid product by MathWorks.
|
| Side note - this flywheel effect determining the long term
| success of programming languages is why discussions around them
| can get so contentious. A criticism of "your" language could
| influence an exodus from the developer community around it,
| making it die slow death. For a person who's put years into the
| language, it could mean throwing away all that knowledge and
| starting afresh elsewhere. So they respond harshly to the
| criticism, subconsciously hoping that the language ecosystem
| stays healthy.
| nextaccountic wrote:
| Julia targets a space that has plenty of free offerings as well
| (like Python and R). Julia is itself open source too, and while
| the founders got work in consulting and cloud offerings, they
| didn't have to lock up part of the ecosystem behind proprietary
| licenses.
|
| I don't see any point in having a proprietary ecosystem when
| open source is so much better in every aspect.
| neolog wrote:
| > they didn't have to lock up part of the ecosystem behind
| proprietary licenses.
|
| That's what JuliaPro (Pumas, etc) is.
| Zababa wrote:
| Your side note is a really good point. I think it's renforced
| today with the reliance on libraries. These days, the "blub-
| iness" [1] of your language is not only the language itself,
| but mostly the libraries. Also, it's easier to wait for your
| language to integrate the good part of others (Java/C# with
| immutable records and pattern matching for example) than to
| change what you use. I sometimes fear that the more time
| passes, the harder it will be to start a new programming
| language.
|
| [1]: In reference to why Lisp over other languages, in this
| article: http://www.paulgraham.com/avg.html
| tester34 wrote:
| Luna Lang / Enso
|
| is visual programming language start up based in Cracow, Poland
| and they even had office in SF iirc.
|
| They have shitton of fancy visualisations, it looks really
| interesting, but I'm personally not the target for Visual
| Programming
|
| https://enso.org/language
| ofrzeta wrote:
| Looks like Quartz Composer on Mac. Which is quite fun to play
| around but in the end I prefer a textual interface.
| RocketSyntax wrote:
| because you have to build an entire ecosystem from scratch.
| that's like asking why there aren't more OS startups
| convolvatron wrote:
| that's the easy part. getting anyone to actually use it...
| smoldesu wrote:
| Because these same "startups" are much more viable as open-source
| projects. Sure it doesn't make much money, but monetizing
| software is an uphill battle anyways.
|
| Plus, you won't get a dime out of me for, say, an AI copilot
| plugin. Unless it's free, and I can guarantee that I'll have
| access to it in the future, why would I want to integrate
| something like this into my workflow? Adding another SAAS into my
| life is just putting my neck under another sword of Damocles.
| davnicwil wrote:
| It is extremely difficult to compete with good enough, and it is
| extremely difficult to compete with free.
|
| There are a plethora of good enough free programming languages
| available, that also have good enough free tooling and
| ecosystems.
|
| There isn't therefore really a business model.
| jeffreyrogers wrote:
| Lot of reasons but mostly because you have to control the
| platform for most new programming languages to make sense. You
| want a new language on Apple platforms that isn't Swift? Good
| luck getting any buy-in from users.
|
| One possible path that might work is if you release your language
| with a framework that is great for some use case. E.g. if Qt were
| rewritten in some alternative language maybe that could be
| successful. But to create anything that polished takes a lot of
| time and effort, so any company is going to burn through capital
| just getting to a place where they can determine if they've made
| something users will actually switch to.
| Apocryphon wrote:
| Does Urbit count?
| dec0dedab0de wrote:
| One of the big reasons is that developers don't want to be locked
| in to something. The tool itself needs to be significantly better
| than the free competition, while still being able to easily pull
| it out and replace it with something else on short notice.
| Startups don't generally like those rules, they tend to thrive on
| lock-in and controlling the users for a chance of a big payday. I
| think developer tools are generally fit more of a "lifestyle
| business" than a startup.
| whateveracct wrote:
| Because "avoid (success at all costs)" makes the best PLs, and
| startups are literally about success at all costs.
| rytcio wrote:
| Jon has talked about this on his "Jai" streams. They need some
| sort of income to fund development of the compiler (hiring more
| programmers to work on it), but the number of people willing to
| pay for a compiler is probably not enough to hire programmers
| api wrote:
| Nobody pays for general use programming languages. The market has
| been conditioned to believe that dev tools should always be free.
|
| Special purpose languages geared toward specific niches like
| Julia may be able to monetize.
___________________________________________________________________
(page generated 2021-07-21 23:01 UTC)