[HN Gopher] The Alternative Implementation Problem
___________________________________________________________________
The Alternative Implementation Problem
Author : mpweiher
Score : 69 points
Date : 2024-05-12 19:49 UTC (3 hours ago)
(HTM) web link (pointersgonewild.com)
(TXT) w3m dump (pointersgonewild.com)
| pfarrell wrote:
| I learned something similar founding a startup. If I could do it
| again, I would have aggressively avoided pursuing the table
| stakes feature in our space. Instead we should have done the
| minimal amount to be comfortable that our architecture could
| support the enterprisey things. We should have then concentrated
| everything on something that would set us apart, something we
| could demo and get a "wow... I see where this could go" instead
| of something like "oh this is just a clone of x".
| Xcelerate wrote:
| If I understand you correctly, you're saying implement the bare
| minimum for enterprise customers--whatever their leadership
| requires to do business with you--but beyond that, forget about
| those features and focus on something very novel that sets you
| apart from the competition?
| AnimalMuppet wrote:
| If you're just like the competition, you lose, because you're
| more of an unknown. If you want to win business, you have to
| have something that your established competitors do not.
| (And, of course, it has to be something that your customers
| want, not just some random thing.)
| michaeljx wrote:
| Kind of like what the iPhone did when they launched without
| copy-pasting, and a very underwhelming gsm radio
| apitman wrote:
| Thias sounds similar to the situation with web browsers. In
| theory they're built on open protocols. In practice whatever
| chrome wants will eventually be where things go.
| ikari_pl wrote:
| it's like this only because nobody except me seems to prefer
| Firefox
| gary_0 wrote:
| I don't use Firefox because it's Firefox, I use it because
| it's not Chrome.
| breck wrote:
| Having worked on languages and compilers for many years, I
| thoroughly enjoyed this post.
|
| Another way to phrase the same idea: a language is _a lot more_
| than just compile speed.
|
| Compile speed is _very_ important, in the top 10 dimensions, for
| sure. Especially because improving compile speed increases the
| developer feedback loop clock speed which helps the core team
| improve all the other dimensions faster.
|
| But there are still >30 other dimensions that are very important
| in a programming language.
| mmoskal wrote:
| The post seems to be about execution speed though. However,
| even there it's definitely not #1 factor as witnessed by
| popularity of CPython...
| miki123211 wrote:
| I'll add one more point which the OP missed, but which is also
| very important. If you're developing an alternative
| implementation, you probably have a different architecture from
| the canonical version, and things that are easy to do in the main
| implementation might be very difficult to do in yours.
|
| Let's say there's a piece of proprietary software for creating
| financial reports[1], which is using a weird binary format to
| store their documents. You want to make a free alternative, which
| can load and save these documents. The format is not fun to deal
| with, so you have a single function that loads the whole document
| into memory and one that dumps your data structures back to disk
| and entirely overwrites the file, but you operate purely on in-
| memory data while the software is running. What you don't know is
| that the proprietary software doesn't do this, it was developed
| in the days when users had very little RAM, so it only loads and
| saves the section the user is currently operating on, and knows
| how to modify the document in-place.
|
| Then, the proprietary software introduces a way to add
| attachments to their documents. People keep adding stupidly large
| files, recordings of investor calls, scanned PDFs with hundreds
| of pages and so on. THe proprietary software loads documents one
| section at a time, so this works just fine. You, on the other
| hand, always deserialize the entire document at once, which
| suddenly becomes a problem when the documents are bigger than the
| users' available RAM memory. You now basically have to re-
| architect the entirety of your software, to support a change that
| took a week of a single developer's time for the main
| implementation.
|
| [1] a purely hypothetical example, I've never actually worked in
| this space.
| phkahler wrote:
| Another less popular take is that people (yes me too at times)
| should check their ego. It can definitely be easier to make "your
| own" parallel project vs contributing to an existing open source
| project, but ask yourself who you're serving. Is it the project
| maintainers? The project itself? The users? Your own ego? Hint:
| if that last suggestion makes you mad it's probably in play ;-)
|
| Adding a JIT to an existing language is a major undertaking, so
| the canonical implementation will have a high bar for acceptance.
| But you should probably still aim for that. Forking or rolling
| your own can provide freedom to do big things too, but that
| should often be regarded as temporary.
|
| If your goal is to show what you can do, it probably won't go
| far. If your goal is to make something better for its good,
| you'll learn to work within others constraints.
| Smaug123 wrote:
| Pff, sometimes the official things are just completely cursed
| and you need to create your own little garden. Even if it does
| turn into twenty acres and a crop-rotation schedule, sometimes
| that's better than a volcano.
| arnorhs wrote:
| Great post. Definitely some great lessons in there.
|
| It's missing a key ingredient though...
|
| I see this as any other competing alternative to any kind of
| product. It's like saying Amazon failed because the didn't have a
| brick and mortar book store like people were used to.. obviously
| that's not the case
|
| The reason all these jit-alts failed and were in a constant catch
| up, is because in practicality, most developers of x-language
| don't care that much about JIT.
|
| Or more importantly, they care more about language features and
| interoperability than they care about JIT. This is why a product
| that "joins them" rather than competing wins. Because you are not
| offering more stability and/or interoperability.
___________________________________________________________________
(page generated 2024-05-12 23:00 UTC)