[HN Gopher] Developer tools can be magic but instead collect dust
___________________________________________________________________
Developer tools can be magic but instead collect dust
Author : todsacerdoti
Score : 170 points
Date : 2021-03-28 18:34 UTC (4 hours ago)
(HTM) web link (www.pathsensitive.com)
(TXT) w3m dump (www.pathsensitive.com)
| azhenley wrote:
| My research is also on dev tools, and I have tried to get my
| research findings adopted. It is hard. Companies often want to
| release incremental, small features, not major UI overhauls.
|
| Even when I've done research at companies or been funded by them
| to study their products, it is virtually impossible to get it
| adopted into the product. Again, the incentives and motivations
| of PMs are very different than researchers.
| acidbaseextract wrote:
| _Companies often want to release incremental, small features,
| not major UI overhauls._
|
| Speaking as a product leader who has been in a position to
| decide on these, I'm not opposed to major UI overhauls, but
| many that have been proposed to me:
|
| - Are motivated by a design team that wants to justify their
| jobs or make a mark on a product, with the UI considerations
| secondary.
|
| - Have major issues and design weaknesses themselves.
|
| - Throw out important aspects of functionality in an attempt to
| be "fresh and simple".
|
| - Ignore that we had our last major overhaul 12 months ago, and
| that one was in response to the major ovehaul 24 months ago.
|
| Requiring evolution rather than revolution is a hedge against
| these problems. I'm not generally opposed to overhauls because
| I'm familiar with the importance of UI. For example, I'm very
| unhappy with Robinhood as a trading platform, but damn,
| switching to Fidelity is painful because their UI is so
| terrible.
|
| I wish I more consistently got to work with talented designers.
| I put a lot of effort into getting good designers, as poor
| designers can wreak havoc.
| k__ wrote:
| What did your research find?
| indymike wrote:
| Here's what makes developer tools hard:
|
| 1. IDE dependency. If you have to use IDE X to get the feature,
| then your tool will live and die by IDE X. A lot of development
| tools lose their user base when an IDE or editor falls out of
| favor.
|
| 2. Language/compiler specificity. This one is rough, because most
| dev tools are dependent on language tooling to do the magic.
| Productivity hitches are different in different languages. In a
| day, I may work with Python, Go, JavaScript, SQL, bash/zsh and
| several DSLs. If your tool doesn't work with 2-3 languages I use,
| I may never even notice your tool. A lot of static analysis based
| tools work well with C and Java and nothing else. It's kind of
| the SmallTalk trap: amazing tools, but you have to use SmallTalk
| to use them.
|
| 3. Solving stuff that really doesn't matter to the programmer. As
| a manager and as a business owner a 15% in developer productivity
| is great. As a programmer, I'm not even going to notice that I'm
| getting 15% more done. And even if I do, it may not even matter.
| Animats wrote:
| _" They later wrote a Java version, jRMTool, but it's only for an
| old version of Eclipse with a completely different API. The code
| is written in Java 1.4, and is no longer even syntactically
| correct. I quickly gave up trying to get it to run."_
|
| _" A few years back, my advisor hired a summer intern to work on
| MatchMaker. He instantly ran into a barrier: it didn't work on
| Java 8."_
|
| _" A couple years ago, I tried to use the Java Whyline. It
| crashed when faced with modern Java bytecode."_
|
| He's answered his own question. Developer tools wear out quickly
| as their environment changes. Unless they have support that keeps
| up with the development environment, they die.
| samatman wrote:
| Okay, but, it wasn't a question, there's no ? in the title.
|
| He was writing a blog post to draw our attention to this
| problem, and succeeded.
| ok123456 wrote:
| This is why version pinning got popular.
| jhgb wrote:
| > About 10 years later, at the Human-Computer Interaction
| Institute at Carnegie Mellon, Amy Ko was thinking about another
| problem. Debugging is like being a detective. Why didn't the
| program update the cache after doing a fetch? What was a negative
| number doing here? Why is it so much work to answer these
| questions? Amy had an idea for a tool called the Whyline, where
| you could ask questions like "Why did ___ happen?" in an
| interactive debugger
|
| Am I just confused, or does it sound like program slicing (1979)?
| azhenley wrote:
| Amy Ko's Whyline is heavily based on slicing.
|
| https://faculty.washington.edu/ajko/papers/Ko2009JavaWhyline...
| SkyPuncher wrote:
| Hmm. I'm not buying it.
|
| Sure, stand-alone developer tools mighte be collecting dust, but
| many tools are simply baked into the things we develop with.
|
| * Extensive debugging tools are now built into browsers. * Most
| popular languages have extensive linters, formatters, and code
| quality tools. * Tools like Hot Loading and Live View simply
| become part of the language you're using. Heck, Hasura and
| Postgraphile are essentially just a set of tools with some very
| intelligent wiring. * Profiling is basically standard on all
| popular languages * Storyboard and component driven design means
| you can quickly translate a lot of design work to code.
|
| The list goes on and on and on.
| actuallyalys wrote:
| I think your points are complementary to the article. It does
| seem like if a tool reaches a certain popularity threshold,
| programmers start porting it to every language and environment
| under the sun. And that often takes the form of building things
| in to larger tools.
|
| But the academic tools this post highlights are typically
| standalone and haven't reached that threshold. My suspicion is
| that the author's point applies most to academic tools that
| have trouble reaching a critical mass.
| veselin wrote:
| I think that tools that collect dust are just not great. The
| article gives some internal Facebook tool as an example, but it
| is really a research paper. I asked some friends at Facebook and
| from my (small) sample I couldn't confirm from anybody to have
| heard of anybody who used the tool, which means it was maybe just
| a PR stunt. This is not a problem for research and it is a great
| paper, but there's just a lot of overselling in the field.
|
| On the other hand, everywhere I worked, developer tools that did
| their job well were easy to adopt. JetBrain is a great example.
| at_a_remove wrote:
| I use very few developer tools, mostly because I couldn't get
| them to stop doing things I hated, or because I couldn't get them
| to stop doing things I didn't need, or because I couldn't get
| them to stop doing things I didn't understand. There's a common
| theme there.
|
| The autocompletion stuff really bothered me because I know what I
| want to type, my fingers are already doing it, and I had to _stop
| them_. I don 't want to learn to retype just for this tool. No.
|
| Certainly, some of them seemed like they would benefit from some
| kind of beginner mode, intermediate mode, and so on. I remember
| not having touched Visual Studio for over a decade, and then
| looking at it and feeling like a chimp dropped into the cockpit
| of an F-15.
| pharmakom wrote:
| Maybe they are not as useful as we thought?
| rodgerd wrote:
| Honestly, my experience is that developers are, on the whole,
| incredibly conservative about changing their ways. When I was
| still an active Java dev, I would, along with a couple of other
| peers, solve a lot of problems in one of our codebase with the
| YourKit profiler, but the use never spread - people would
| prefer to grind out the thing they already know and thrash
| around blindly to spending a day or two learning an easier way
| of solving a problem.
| gmiller123456 wrote:
| Granted, if I had a nickle for every profiling tool that
| claimed to make code easier, more secure, faster, etc which
| didn't live up to its promises, I wouldn't need to work
| anymore.
|
| It's great that you found one that worked in your particular
| situation, but my exerpience has been quite the opposite. And
| it's not from a lack of being forced to try.
| tracyhenry wrote:
| or the academic people are not interested in putting in the
| effort to maintain the tool in order to get more adoption.
| azhenley wrote:
| We aren't incentivized to maintain research prototypes. On
| the flip side, industry seems to have very little interest in
| adopting our findings into products.
| tracyhenry wrote:
| > We aren't incentivized to maintain research prototypes
|
| There are still examples where research prototypes have
| evolved into successful products, either as open source
| projects or commercial companies. The researcher needs to
| be passionate enough about getting adoption and real-world
| impact in order for this to work.
|
| > On the flip side, industry seems to have very little
| interest in adopting our findings into products.
|
| IMO, developer tools need to be wayyyy better to overcome
| inertia. This statement might not hold in other fields,
| e.g., ML/AI.
| slx26 wrote:
| This is all rather vague. These tools collect dust because
| software nowadays doesn't only have to be written, it needs to be
| maintained and adapted. And these examples weren't because they
| weren't useful enough. Sure, they worked at their specific
| task... but none of them was a game changer or enhanced the power
| of the developer in general. It's not that dev tools are not
| used, just that most of them are directly written by the
| programmers that need them, for their own use, without much care
| for life expectancy or limitations. Just to get that thing done
| when they need it. I don't really understand much the point of
| the article. If an idea is good, well executed and presented to
| its target audience, maybe it won't eat the world, but it will
| have decent chances to not collect dust.
| barefeg wrote:
| In my opinion this article is a cry from people that don't
| understand how to find a market fit and then "sell" their idea.
| I think it's pretty typical point of view from academics that
| their idea is ground breaking and should be know by everyone.
| However, things don't work like that in the real world.
| Meritocracy doesn't make the best tool rise to the top. You
| also need to solve a problem for a huge amount of people and
| then do a bunch of PR and educate.
| phone8675309 wrote:
| > These tools collect dust because software nowadays doesn't
| only have to be written, it needs to be maintained and adapted.
|
| Everyone loves making and using a new, shiny, "life changing"
| tool. Very few people would stick around at a job (or indeed,
| apply for a job) to maintain that tool.
|
| Creation is easier compared to understanding and adaptation to
| change.
| dstick wrote:
| Didn't sound vague to me at all. I learned a few things from
| the article and I would pay a hefty premium to have that
| "Whyline" debugger in Phpstorm.
| slx26 wrote:
| The point the article was trying to make, not the tool
| descriptions. Though to be fair, the point was probably only
| to showcase some cool ideas to inspire people to consider dev
| tools more. Maybe I tried to read too deep into it.
| heavenlyblue wrote:
| "Whyline" debugger is useless if you are trying to understand
| why your LIVE code ended up in a certain state; unless you
| are ready to run your live code in a debugger.
|
| Finding all places where the variable had changes is on the
| other hand easy without Whyline.
| crb002 wrote:
| Twitch streams help. A lot of tool skills don't get transferred
| because they are un-observed.
| hypermachine wrote:
| Because in 2021 developer tools are fundamentally not profitable.
| Jetbrains is the exception, not the norm. Developer tools are
| loss leaders for large corporation to acquire developer goodwill
| and mindshare. Previously we sold developer tools/PaaS.
| Programmers do not like to pay for their tooling. You have to
| sell to management, and when your target is management, then the
| metrics are completely different from what developers want.
|
| This is why no-code and low code are so much more successful than
| developers tooling startups in terms of revenue and
| profitability. The people using are the same people who are
| running the business. The value proposition is clear. "Better
| developer experience" alone is not sufficient for selling to
| enterprise. And programmer productivity cannot be quantified in
| lines of code written. This is hard point to explain and get
| across on HN because this forum is inherently dismissive of the
| value of RPA and RAD software.
| elorant wrote:
| I've paid thousands through the years to buy various versions
| of Visual Studio. While there are free alternatives I don't
| even bother paying the money because of the value that
| beautiful piece of software offers me.
| donmcronald wrote:
| > Programmers do not like to pay for their tooling.
|
| Eventually they'll have to. Everything is trending to SaaS
| offerings and eventually we'll be paying way, way more. The
| amount of money people spend on SaaS CI blows my mind and if
| that's any indication the move to massively over priced SaaS
| tooling is inevitable.
| Silhouette wrote:
| I'm not sure I buy this argument. The one group of people who
| certainly can create good alternatives that don't rely on
| that lock-in effect are programmers, after all. It's their
| livelihoods and happiness we're talking about, not to mention
| often their own pockets feeding the SAAS beast in the case of
| small businesses and freelancers, so they have a lot of
| incentives to do exactly that. And there are millions of
| them, many of whom already contribute freely to projects they
| find interesting anyway.
| DistressedDrone wrote:
| SaaS CI is valuable because it's not seen as something a
| programmer could easily make by themselves, unlike the vast
| majority of SaaS offerings, a lot of which are more marketing
| than code (not that that's a bad thing, but don't ask the
| average programmer how highly they value marketing).
| vbezhenar wrote:
| May be I'm missing something, but CI looks like the thing
| that's trivially implemented by a few bash scripts. It
| won't be as pretty and as reliable compared to battle-
| tested service, but generally it'll work. I did that in the
| past and it worked pretty well for our uses.
| devoutsalsa wrote:
| I remember going to a sales pitch for proprietary mobile app
| automated testing software . I was the developer looking at
| this product. It had crap documentation, it was hard to use,
| and our mobile app was not designed to be testable. But
| internal efforts to improve the speed at which QA happened were
| slow. Even though this software was crap, management bought it
| because it was a problem they could through money at to try and
| buy their way out of not listening to developers. We wanted to
| make the app testable and use free, open source tools that
| would actually work.
| emrah wrote:
| > Programmers do not like to pay for their tooling.
|
| Maybe not for their personal/hobby projects, but they wouldn't
| be the ones paying for tools at work.
|
| So it's the companies not willing to pay for dev tools or
| understand the value they can provide
| macjohnmcc wrote:
| yeah nearly every developer I encounter does not want to pay
| for anything. Yet they love to get paid to program. An odd
| disconnect there for me.
| infoseek12 wrote:
| Yeah nearly every person I encounter does not want to be
| eaten. Yet they love to eat. An odd disconnect there for me.
| rowanG077 wrote:
| The disconnect is not odd for me. Developers know you will
| essentially pay for a sub-optimal experience. Proprietary
| software vendors almost always treat their users as dirt. The
| piece of software would almost always be better if it were
| open source. And developers know this.
| DistressedDrone wrote:
| I don't see it as a disconnect, my baker friends seldom buy
| bread and I suspect jewelers seldom buy jewelry for example.
|
| Why buy when you can make?
| wodenokoto wrote:
| That is not my impression at all.
|
| All the chefs I know go out to eat way more than anyone
| else I know (don't know any bakers, though). Graphic
| designers I know, buy art and graphic designs (don't know
| any jewelers, either). Musician friends buy tons of records
| and tickets to live shows, friends who brew, buy more beer
| than friends who don't brew.
| Spivak wrote:
| Software is a fun field where the people who make it want
| to consume as little of it as possible.
| DistressedDrone wrote:
| I can't deny that this is plausible (in general I mean,
| not just your specific experience). So what makes our
| professions so different?
| deviantfero wrote:
| You can make unlimited copies of software would be my
| first guess
| jariel wrote:
| The disconnect I don't think is about protecting their
| turf.
|
| I think it's mostly about 1) not having an instinct for how
| powerful the tools are and 2) not being able to internalize
| the value of leverage vs. cost.
|
| $1000/year 'feels' expensive to a developer. That's 'a lot
| of money'.
|
| But if it makes you >1% more productive, it's worth it.
|
| Some of these tools are not just productivity enhancements
| but multipliers.
|
| But that takes a different kind of intuition that very few
| people have naturally, you kind of have to be in a position
| to make those decisions.
|
| Those that have the instinct often are not programming.
| cortesoft wrote:
| > But if it makes you >1% more productive, it's worth it.
|
| Does it, though? I get paid for my time, not my
| productivity
| wccrawford wrote:
| You get paid right now for your time.
|
| You get paid next year a rate based on how productive you
| are today.
|
| Even when companies don't give proper raises, this still
| ends up applying when you quit and go to another company
| because you've spent x% more time actually coding instead
| of waiting or busy work, and you can command a higher
| salary.
| MattGaiser wrote:
| > But if it makes you >1% more productive, it's worth it.
|
| For an individual, it depends on whether your
| compensation is tied closely to productivity or
| multiplication.Being 1% more productive is not going to
| get your average person anything in a corporate
| environment.
| fiddlerwoaroof wrote:
| I've paid for various tools over the years: ultimately,
| I've never really found that the commercial tools are
| significantly better for the problems I have. I've
| generally found that Emacs and/or Unix shell utilities
| make it really easy to make a tool that solves exactly
| the problem you have while commercial tools end up having
| frustrating limitations or are really hard to learn
| because they solve the general case instead of the 70%
| case that you actually have.
| agumonkey wrote:
| to me it's more like "the value of this thing i do is for
| others to be happy"
| sxg wrote:
| Because you can't make every tool you'll need to program
| effectively. Unlike bread, which only takes hours to make,
| good tooling will take months to years if done yourself.
| cortesoft wrote:
| Yeah, but a baker also can't make one loaf of bread that
| everyone can then eat forever.
|
| In software, you actually can have your cake and eat it,
| too.
| [deleted]
| jrockway wrote:
| I think there is some bias in that younger developers are the
| ones with the time to share their opinions over social media,
| but also have the least amount of money / influence with
| which to buy tooling. Certainly, when I started programming,
| I didn't have any budget for tools. I was lucky to even have
| a computer. Thus, I had no choice but to use free tools.
| People hold on to that experience long past the point where
| the monetary cost of tooling is meaningful.
|
| Influence is the biggest problem, which is why I mention the
| junior vs. senior divide. When you want to buy software at
| work, you aren't typically given a budget and a credit card
| with which to buy the tooling. You have to justify every
| case. No junior developer wants to be the squeaky wheel
| that's always begging for cash for tooling, so they do
| without. Or, if they do decide to buy tools, they're met with
| the "alternatives analysis" phase of approval -- you invested
| time learning this tool that you now want to buy, go do that
| three or four more times while still completing your normal
| work, to make sure we don't waste any money. (You can see why
| writing your own stuff from scratch is so popular -- no
| approval process. You just do it.)
|
| Tools are also special in that they come with a time cost and
| a dollar cost. I have never seen a product that will save me
| time without any effort on my part, but would love to buy
| such a thing if it existed. Instead, you have to pay the fee,
| and then learn the software. (So the actual cost is your
| hourly rate * the time to learn, plus the actual dollar cost.
| At least free projects or writing it yourself don't have the
| actual dollar cost. The training cost leaves the most sour
| taste in my mouth. I've wasted countless hours reading,
| excuse the term, dogshit, documentation for something I paid
| a lot of money for. Every time this happens I think to myself
| that writing a version of this software that actually works
| would have taken longer, but at least I'd be enjoying myself.
| Never forget that your mental health has value.)
|
| Finally, software vendors are doing a terrible job, in
| general, of pricing their product for the developer market.
| The biggest problem that I run into is per-user pricing. It
| gets costly very quickly, either in money or in toil. The
| monetary cost scales with the number of people that use it,
| and if you want to avoid the anguish of deciding who is a
| first class citizen that gets access and who is a second
| class citizen who has to beg someone with access to do
| something for them, you have to buy an account for every
| user. Even for things that one person may use once a year,
| you take a lot of autonomy and the potential for ownership
| away if they can't use the tool. But, they charge you like
| every user is using it for 8 hours a day, 40 hours a week.
|
| Personally, that has been a recurring problem for me. The
| tools that take me longest to get approved are minor
| productivity enhancers with per-user fees. Tools that have a
| per-organization or usage based cost are easy. (Examples:
| CircleCI, Sentry.) Tools that have a per-user fee are
| hardest. (Examples: Github, Codecov, Cypress Dashboard,
| Retool.) I work on a cloud service that had a per-user
| charge, and it went exactly as I expected -- few people would
| sign up, and when they did, they shared accounts to keep the
| cost down. We changed it to a usage-based fee, and a month in
| the people that actually sign up and start using the service
| increased dramatically. No longer do customers hit a paywall
| where their 0 -> some usage costs an amount of money that
| requires an in-depth approval process with their higher ups.
| No longer do customers hit a wall where some team members
| have to be made second-class citizens that can't use the
| software. People can gradually go from a $0 bill to a $0.01
| bill, and invite everyone on their team to contribute,
| without having to come up with some way to share accounts.
| It's really great, and everyone that sells per-user licenses
| should think long and hard about how many people they are
| flat-out turning away.
|
| Anyway, my point is that developers aren't selfishly
| collecting money without spending it on software. I'm sure
| they'd love to, but there are a vast number of complications
| standing in their way. Remove the complications to collect
| their money.
| dlojudice wrote:
| > Because in 2021 developer tools are fundamentally not
| profitable.
|
| Interesting...
|
| But monetization might not be the root of this since we have
| very sophisticated tools delivered as open source. The question
| then would be why the "dev comunity" is not interested in
| building tools like those mentioned in the article?
|
| My guess is that tools like Reflexion Models doesn't ring any
| bells for junior/mid-level developers. They don't know exactly
| what to optimize when it comes to long-term maintenance. That's
| why we have so many parsers, linters, etc. and now typed
| languages (again!) and not Reflexion Models.
|
| The other day I was looking for something similar to Reflexion
| Models: a tool that I could describe high level modules and its
| files (like a package), describe the dependency hierarchy
| between then and check if there is any calls between modules
| that break the hierarchy. For instance: getting a alert if
| there is a call to a repository from the a controller (DDD).
| It's a common problem for big teams with junior developers that
| could be solved by automation.
| kungito wrote:
| Senior developers with 20 years of experience do not
| "believe" in debuggers, IDEs or writing tests. Same things
| are reinvented every 3 months with a new name written in a
| custom font. We are in many ways still in the bronze age of
| software development.
| heavenlyblue wrote:
| Debugger is just a nice interface for prints.
|
| IDEs should be replaced with libraries that allow one to
| operate over the code (or make IDEs allow you to script
| their AST manipulators)
|
| Writing tests is not connected to the two above.
| dan-robertson wrote:
| That's definitely not what a debugger is. You can't add
| prints to a coredump and the run->add
| prints->compile->loop sucks a lot, especially if the bug
| is hard or slow to trigger.
|
| I think the main promise of an IDE is being integrated.
| But maybe it could just be done with libraries.
| dmz73 wrote:
| Debugger might be a nice interface for prints in kernel.
| It is also not usable with distributed systems where
| prints are also not all that useful and you need some
| kind of central logging. But developing a desktop
| application without debugger is like writing code with a
| line editor. It can be done but it is not very productive
| (I can still remember editing BASIC programs one line at
| the time).
| GiorgioG wrote:
| > Senior developers with 20 years of experience do not
| "believe" in debuggers, IDEs or writing tests.
|
| Speak for yourself. I've been paying for my own developer
| tooling for 25+ years.
| MattGaiser wrote:
| What do you find to be worth purchasing?
| pjmlp wrote:
| Which is why I grew disappointed with FOSS and decided I was
| happier working for the enterprise overlords, where such tools
| are common.
|
| It is incredible how so many devs don't want to pay for
| tooling, yet expect people to pay them.
|
| Here is an idea, what about being paid in the exact amount that
| one is willing to pay for their tooling.
| ris wrote:
| > Here is an idea, what about being paid in the exact amount
| that one is willing to pay for their tooling.
|
| A better idea: what if all companies had to pay for _all_ the
| software they expect to make money using, right down to the
| metal? No leeching off linux for you. Also no gcc, llvm,
| postgresql, mysql, python, ruby...
|
| When people try introducing proprietary software into the
| FOSS ecosystem, I find it _equally_ "incredible" how little
| they acknowledge that most of their piddly 10k lines of
| "magic" depends on the tens of millions of lines of code
| underneath being written by people who decided to take the
| other path.
|
| It sounds like you're better off out of FOSS, but I can
| guarantee your job is propped up by its existence, almost no
| matter what you do.
| maxrev17 wrote:
| Developers are a tough market (I am one). They're also a pain
| to manage, expensive, and still human(ish - if you're lucky)
| :p, with all the ego and mistakes that come with the territory.
| No-code for simple wiring/boilerplating once good enough/widely
| adopted enough, will kick our asses. But then again on the
| opposite side, in many cases business types bring mainly money
| to the table, leaving the expensive nerds to do the rest, and
| have fun with their RG machines in the process.
| DistressedDrone wrote:
| > No-code for simple wiring/boilerplating once good
| enough/widely adopted enough, will kick our asses.
|
| By "our asses" I assume you mean programmers'? I don't buy
| it. People think coding is hard because they think thinking
| is hard. No-code doesn't remove the latter part, it'll only
| make things easier for programmers.
|
| If anything it makes getting into programming easier, but
| that means more programmers not fewer.
| jude- wrote:
| The history of abstracting the hardware as something easier
| for people to understand is exactly the history of
| programming languages.
|
| Wake me up when someone writes a compiler that reliably turns
| "Hello computer, please make me money" into an executable.
| MattGaiser wrote:
| > Programmers do not like to pay for their tooling.
|
| Because it is too much work to convince the company that
| spending $500 on JRebel to have me not go on Hacker News for 5
| (and it turns into 15) minutes while the thing compiles (my
| last company). I also have no real stake in whether the product
| ships in one month or two so I am not paying for it myself.
|
| To pay for tooling, productivity needs to be a priority. I have
| never worked anywhere where productivity was discussed.
| FroshKiller wrote:
| On my team of three, my teammate and I had to create a
| presentation for our project leader that he could share with
| our director making a case for buying ReSharper licenses for
| the two of us. Then of course our director declined to spend
| the money. It was tedious and infuriating.
| MattGaiser wrote:
| You were probably paid more in salary to make that
| presentation than those licenses cost, lol.
| bcrosby95 wrote:
| Some companies will care. Some won't. I mentioned something
| like this to mine and they upgraded the build server in
| response.
|
| For Jetbrains products, if you enjoy them you can use your
| personal license commercially. Your company just can't pay
| for it or reimburse you for it. This is the route I go
| because I use their products for personal projects too. For
| me it's a no brainer at $150/year for their all-products
| option (...for the 3rd year, 1st is $250, 2nd is $200).
| XorNot wrote:
| I do this as well - its pretty easy to justify a Jetbrains
| Ultimate subscription for myself since it makes life so
| much easier.
| MattGaiser wrote:
| I get this for free with an annual UX interview, but yes I
| would pay for Jetbrains personally.
| apple4ever wrote:
| That is all way too much money.
|
| If they want more adoption, they need to be under the $100
| mark.
| MattGaiser wrote:
| That's the price for an all you can code subscription to
| everything. Individual licenses are much cheaper.
| initplus wrote:
| Charging for developer tooling is really hard.
|
| Over-monetizing their dev tooling was a significant contributor
| to Microsoft's loss of dev mind-share over the last decade.
| Free software took over the world because any kid in their
| bedroom could download Linux/GCC/MySQL for free.
|
| Want to work in .NET/MSVC? You just run into barriers (gimped
| "express" versions, no free documentation etc.) Yes this has
| changed now, but it's been a long time coming.
| nhumrich wrote:
| Similarly, I see people leaving jetbrains every day. VS Code
| is getting better and better, and jetbrains tools are
| becoming more and more niche. While jetbrains may always be
| ahead, the gap is widening.
| ftruzzi wrote:
| VS code with Python is just frustratingly buggy. The only
| reason I'm forced to use it is the WSL/remote integration.
| Pycharm just works.
| cratermoon wrote:
| Every time I change developer tools it's because the one
| I've been using has become bloated with add-ons as part of
| the install. When the installer has options for choosing
| packages, they aren't granular enough to be worthwhile. So
| the IDE becomes a hinderance, using memory, CPU, and screen
| real estate intrusively. JetBrains is there now, but it
| still has better language support for my needs than
| anything else more lightweight. I use VS Code for
| everything unless I absolutely need to fire up JetBrains.
| luckylion wrote:
| > So the IDE becomes a hinderance, using memory, CPU, and
| screen real estate intrusively.
|
| The screen space used is highly configurable, but if it
| wasn't, I'd agree. I don't care about memory or CPU at
| all.
|
| Maybe it's different for other languages, I mostly do PHP
| + JS/HTML/CSS, but PHPStorm vs vscode (+ plugins for
| both) is not even close, and PHPStorm makes me so much
| more productive and takes so much annoyance out of my day
| that investing in a beefier machine seems like a small
| price to pay. I've easily made that money back once a
| month just because I get more done.
|
| I like vscode, but I pretty much exclusively use it as a
| text editor and notepad.
| jdsully wrote:
| Not sure what you mean by "no free documentation" but even
| when I worked there we just used MSDN's free online website
| like everyone else. VS did cost $$ but not sure it was
| overpriced, I'm still less productive on Linux than I was
| with the real VS (code is nice but not the same). I'd pay for
| a Linux version in a heartbeat.
|
| The real reason Linux took over is Windows just didn't make a
| good server. Even if you looked past the bloated footprint,
| licensing was a nightmare just to figure out what you needed
| to buy let alone the licensing costs themselves.
|
| Even good dev tools can't make up for a bad platform.
| horsemans wrote:
| I believe by "no free documentation" they are referring to
| the 90s, where MSDN was a subscription service, hence the
| "long time coming" comment.
| laurent92 wrote:
| > I'd pay for a Linux version in a heartbeat
|
| We should enter a world where people pay for open-source.
| OSS has been fine, but they never had the correct resources
| for marketing and UX. The should be a paywall for access to
| repos, even if you could theoretically find the code
| everywhere else, but ey, want the code updated
| automatically? $5 per month. (I'm paying 1% revenue for OSS
| but as long as it's not everyone, it doesn't make the
| developers filthy rich and able to hire UX and marketers,
| and that is what we need).
| apple4ever wrote:
| It is but also the price has something to do with it. They
| are all hundreds of dollars.
| dchichkov wrote:
| There is also no VC money in this. Even mature areas like
| static code analysis are a dead water.
|
| There will be a renaissance in tooling, once AGI is realized ;)
| jariel wrote:
| Part 1 yes. Part 2 ... no.
|
| 'No Code' generally have a different use case. For every
| 'software project' there are probably 5x as many 'simpler
| projects' that require a basic front/backend but not much
| material CS knowledge, and that's where no-code shines.
|
| 'No Code' should be a euphemism for 'Didn't Need Code In The
| First Place'.
|
| In other words, there's a legit level of abstraction there with
| it's own world of tooling etc..
| megameter wrote:
| The kinds of tools like those in the article suffer from being
| outside of the "main loop of coding".
|
| What is the main loop? Well, as it's defined since the rise of
| interactive computing, it's typing in the editor, compiling, then
| testing and debugging.
|
| Thus we optimize for:
|
| 1. Typing code fast(or typing less code)
|
| 2. Compiling code fast(by doing less compilation)
|
| 3. Minimizing testing and debugging time(by narrowing our
| definitions of testing to that which is easy to automate).
|
| The main loop of coding is not software development. It does not
| study the domain problem, define new benchmarks for success,
| untangle communication issues, or refine principles of
| development. It is a path to coder flow state, feature factoryism
| and shipping the org chart. These things sort of resemble
| development - a happy coder delivering features within a definite
| architecture does serve someone at some point - but also manifest
| dysfunction. Development failing is just shrugged off as bad
| programming or bad management.
|
| Tools like a Whyline or Reflexion models are not in the main
| loop. They are an invitation to look carefully at whatever horror
| has been wrought and address it at a deep level. But that really
| needs a researching mindset, not a shipping one.
|
| In practice, the available tools very slowly move in the
| direction of the suggestions of research. There are improvements,
| but they need projects that put together the pieces and make it a
| goal from the language design(the main interface) upwards.
| heavenlyblue wrote:
| Whyline would not help you understand why a multiplication of
| two million by million matrices gave a 0.7374920 in row 6478
| column 474995.
| dan-robertson wrote:
| What would tell you that?
|
| But also, what percentage of typical code is multiplying
| massive matricies and what is doing simple arithmetic or data
| transformation or rpcs?
| klyrs wrote:
| The common thread I see in this is people pouring their heart and
| soul into a super awesome tool, and then moving on with their
| lives. The tool was made for one version of one language, and the
| world moves on, too. But then I think about the tools that I _do_
| use.
|
| Package distributions. Good word, I am not happy here. Still an
| unsolved problem in general, some languages tackle it better than
| others.
|
| Testing frameworks. It's getting better. Big props to zig, for
| including tests for free with comptime. But in general, it's
| piles of code that somebody maintains for each language. Often,
| there are multiple tools because the language devs don't pull
| them into first-class components.
|
| Debuggers. There's pretty good tools out there. They're clunky to
| use, but there are multiple front ends that can handle multiple
| languages, thanks to a common data format.
|
| Code formatters. Props to zig, go, and rust for building these
| in. But for most languages, it's DIY.
|
| Common theme here: all of this stuff is fairly generic, but each
| language tends to do its own thing. Tools aren't officially part
| of the languages, neither are they generic. Except debuggers!
| There's a common interface, DWARF support becomes a part of the
| language, and (another key point) language devs use it -- so they
| don't rot.
|
| Developer tools can be magic, but unless they're generic, I
| expect them all to rot.
|
| Edit: Oh, I forgot documentation generation -- like debugging,
| there's been some convergence around some generic tools and it's
| pretty easy to build support into / on top of a language. And
| newer languages use these tools internally to build their docs.
| Great!
|
| And how could I forget compilers! LLVM might save the day for
| _all_ of this stuff (except versioning and distribution... ick).
| Build a tool that can grok LLVM-IR, and you 've solved the
| problem for most languages out there.
| Lucasoato wrote:
| Am I the only one who finds strange that now even a jetbrains IDE
| plug in such as Material Design UI has a monthly subscription?
| jldugger wrote:
| > The reason that Reflexion Models are obscure while Mylyn is
| among the most popular Eclipse plugins is quite literally because
| Gail C. Murphy, creator of Reflexion Models, decided to go into
| academia, while her student Mik Kersten, creator of Mylyn, went
| into industry.
|
| > Other fields of computer science don't seem to have such a
| giant rift between the accomplishments of researchers and
| practitioners.
|
| I'm not sure that's actually true. I can't think of a field I've
| studied where research generated software from a decade ago still
| worked out of the box. If you write software for Java 7 that
| proves your concept is feasible, the existence of Java 14 doesn't
| disprove it, so nobody funds the research to port it. This is as
| true for bioinformatics as compilers.
|
| There's also a pretty strong hurdle in simply educating the
| software development community. I suspected if you did a
| sufficiently large poll of developers, less than 5 percent have
| set a breakpoint and used a debugger in the past year. It seems
| even renowned experts believe debuggers are not valuable[1]. And
| I suspect at least half of people who claim proficiency in git
| can't correctly explain the difference between the rebase and
| merge commands.
|
| And that, IMO, is the mystery we need to explain. If the
| hypothesis is that weak but free tools are undercutting the
| market for advanced tools, why don't developers learn and use the
| tools freely available to them? Are the tools too hard to learn,
| not powerful enough, or something else? I suspect there's a time
| tradeoff going on -- learning how to use a tool takes time, so if
| you believe you have a slow method that will solve the problem,
| you might prefer it to investing in learning something new.
| Especially outside the research lab, where there is uncertainty
| that any given tool will actually solve the problem at hand, and
| a researcher hasn't handcrafted a tutorial to make your assigned
| task feasible.
|
| [1]: https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/
| stevage wrote:
| I think my lesson here is that Java is a terrible language for
| software longevity.
| ptx wrote:
| If the program was written to manipulate LLVM bitcode instead
| of Java bytecode it would have fared even worse.
|
| It would be interesting to know the specifics of the syntactic
| incompatibilities in the Java 1.4 program, since Java is
| usually extremely conservative when it comes to syntactic
| changes.
| softwaredoug wrote:
| Programming language interpreters are tools. How do Python, Node
| and Ruby survive? How about the core tooling? Are the devs well
| paid to work on this? Do they do it just because they love it?
| How do the foundations around these tools get money to support
| their work?
| [deleted]
| The_rationalist wrote:
| One kind of magic kind of tool that I have never tested is time
| travel/omniscient debugging E.g
| https://undo.io/solutions/products/java/
| 6gvONxR4sf7o wrote:
| It's a shame there aren't too many cross language tools. You
| build your clever new tool for Java and python devs get it for
| free. As I understand it, language servers are an attempt to do
| some of that. I wonder what extent that line of thinking applies
| to more sophisticated things like OP is talking about. Or are the
| commonalities between languages only limited to surface level
| magic?
| WrtCdEvrydy wrote:
| We've done this now with JSON APIs... even most libraries now
| just a JSON API and then give you a language binding.
| IncludeSecurity wrote:
| On the security assessment side of tech we face similar problems
| that these types of awesome dev tools could help us solve.
|
| Our clients either: 1) Have no docs (48%) 2) Have
| outdated/incorrect docs (48%) 3) Have correct and updated docs
| (2%)
|
| Tools to understand source code/app architecture and increase
| understanding would make application security easier since there
| would be less incorrect assumptions and those doing security
| assessments would be much more effective and efficient in their
| work.
| zlynx wrote:
| These tools are mostly useless because they take time to discover
| and learn to use. In the meantime you could have solved the
| problem. Developers who waste all their time searching for a
| magic tool are not productive.
|
| They're also often not integrated into whatever environment is in
| use. Which means the developer has to be sure to save their
| files, open this other tool, which has often not been updated to
| new standards, wait for it to load their JAR files or whatever,
| and then use a ten year old interface to use the "magic".
| geophile wrote:
| As many on this discussion have noted, JetBrains tools not only
| don't collect dust, they are widely used, and the company is
| profitable. The company is privately held. I hear that they are
| constantly turning down investments. This proves 1) there _is_
| money in tools; 2) The VCs who routinely say "there is no money
| in tools" are insufficiently imaginitive, which is not surprising
| if you've spent any time with VCs.
|
| Why is JetBrains so successful where others have failed? A few
| thoughts:
|
| - Intellij was released in 2001. Eclipse was a close competitor
| for a while, which made no sense to me. Intellij just worked, and
| it was intuitive. I found Eclipse to be uglier, slower, flakier,
| crashier, and far less intuitive. Haven't heard of it in years.
|
| - It was always the case that at least some version of Jetbrains
| tools are zero cost. I got hooked on it early on. I have been
| using emacs far longer, and yes, while a sufficiently dedicated
| developer can make emacs behave like an IDE, it really isn't one.
| Intellij just worked out of the box. In the preceding two
| decades, there were high-end development tools available (Lisp
| machines and their all-encompassing environments, Lucid for C++,
| Purify for C/C++ memory problems, Atria, Rational. Trivia: Did
| you know that Purify was founded by Reed Hastings, the guy who
| went on to found Netflix?) The tools were expensive, and I don't
| think there were free versions. These companies all went out of
| business, or were acquired.
|
| - Jetbrains is incredibly focused. Having been through several
| VC-funded technology companies, I can easily see how VC brain
| farts can destroy a company's focus. (This dynamic isn't entirely
| the VCs fault. Founders stretch the truth to get funded, and then
| VCs insist on the fairy tales they've been told.)
|
| - Jetbrains has expanded to other languages, and other kinds of
| tools (besides just refactoring Java code). The number of
| languages, technologies, and frameworks that they support is just
| mind-boggling.
|
| - Consistent focus on improving developer's lives, through steady
| improvements in functionality, performance, and quality, over 20
| years at this point. They started far ahead and have widened the
| gap.
|
| OPs tools look useful. I suspect they would attract a much wider
| audience if made available through Jetbrains products.
| cortesoft wrote:
| I always have this weird sensation when people talk about
| Jetbrains.... I feel like some in some circles, usage of
| Jetbrains tools is ubiquitous, while in others it is unheard
| of. I have been a professional software developer for 15 years,
| and have never seen the tools in use anywhere I work. But I
| read things on the internet where people will say things like
| "well, every ruby developer uses Jetbrain" and seem to not even
| question this.... weird how circles like this form.
| alde wrote:
| Yes, odd. Data point: me and most of my SE friends/coworkers
| pay for JetBrains IDEs (I was pretty deep into emacs and vim
| for many years prior to switching).
| mikewarot wrote:
| I found the ideas embedded in the examples to be quite good
| ideas, if we can get them instantiated.
| uyt wrote:
| I think the "WhyLine" idea is already mainstream, at least for
| web UI development.
|
| I remember back in the days, if you wanted to know "why" a html
| is the way it is, you just had to change/delete random parts of
| it and see what breaks. After firebug was introduced (mid
| 2000s?), you can just right click to inspect element and it will
| highlight the html element responsible for it.
|
| Nowadays, I am reasonably happy with the type of questions that
| the chrome dev tools can answer with just a few clicks. Why did
| some network request fire? There's an initiator column that links
| to the source code. Why did this frame take so long to render?
| There's a flame graph where each bar links to source code. And
| there are plenty of extensions you can install to help with the
| particular level of abstraction you're debugging at (for example
| inspect React components instead of html elements).
| [deleted]
___________________________________________________________________
(page generated 2021-03-28 23:00 UTC)