20 ms·

This is yet another example of the divide between wizarding and engineering[1]. When you're a small startup, what matters is the expressiveness of your language

• ben_jones 7y ago
  What you call Wizarding I call "ordinary Software Development". A software developer spends ~70% of their time writing features and the rest mixed between organization/planning/roadmapping etc. A software engineer spends ~30% of their time writing features and the rest of it managing technical debt and making long-term investments towards better features and processes. Too many companies need devs but have engineers, or they need engineers but only have devs :/
  • heartbreak 7y ago
    I’ve never known anyone to distinguish between the two roles, and they seem to be used interchangeably in the industry. (Except those people who claim software engineers aren’t real engineers)
• TylerE 7y ago
  Who is starting large-scale new projects in Java in 2019?
  • victor106 7y ago
    One of my clients handles 90% of all the pbm routing in the US, which is millions of transactions per second. They started to completely modernize the application on java... primarily Spring Boot and Apache Geode. After some optimizations they are very happy with the performance and expressiveness of modern java.
    • TylerE 7y ago
      I said new projects. Not upgrades.
      • GordonS 7y ago
        Not the OP, but I understood their comment to mean 'a rewrite in Java of a legacy system written in some other language'?
        • victor106 7y ago
          Exactly right. Java has lots to improve on but there seems to be unsubstantiated hate towards Java on HN which I find contrary to what happens in the real world. In the real world companies find hiring Java programmers relatively easy (maybe not the best and brightest) who can get a project off the ground easily
  • pjmlp 7y ago
    Plenty of companies free of magpie developers.
    • TylerE 7y ago
      I asked for examples, not platitudes.
      • pjmlp 7y ago
        Pick random names out of Fortune 500 companies. Java projects get done all the time. Additionally, even though it isn't standard Java, I have plenty of new apps running on my pocket.
• bcherny 7y ago
  > I wish there was a language that let you move gradually from one end to the other, exactly when you need to. This is precisely what gradually typed languages — like TypeScript, Flow, and typed Pythons — solve! I talked about this on Software Engineering Radio last week: https://www.se-radio.net/2019/10/episode-384-boris-cherny-on-typescript/ https://www.se-radio.net/2019/10/episode-384-boris-cherny-on....
  • spraak 7y ago
    Typescript was exactly what I was going to mention in reply
  • paulddraper 7y ago
    TypeScript is perfectly this. (And other gradually typed solutions; TS is simply the most popular one.) You have the madness of thousand of developers flinging code at the universe due to the easiness of browsers, JS, and npm. This results in great speed, but not great quality. When your project/company now wants quality, you keep your code but transition to types. (In OSS space, Angular and Yarn projects have both done JS => TS migrations of some form.)
    • ashishb 7y ago
      Afaik, typescript is pretty bad in terms of catching some basic errors. Types are not enforced. A caller can change sync function to async, breaking the functionality downstream.
      • xzel 7y ago
        You can decide if they're enforced or not. That is part of how it is gradual typing.
      • paulddraper 7y ago
        Yes gradually typed languages are usually looser/more flexible about static typing. > A caller can change sync function to async, breaking the functionality downstream. I think you mean callee? Are you taking about using a returned result? Because most languages permit ignoring return values. If you want to check out promise use, check out https://tsetse.info/must-use-promises https://tsetse.info/must-use-promises
• zitterbewegung 7y ago
  You can write fortran in any language. [1] https://blog.codinghorror.com/you-can-write-fortran-in-any-language/ https://blog.codinghorror.com/you-can-write-fortran-in-any-l... [2] https://queue.acm.org/detail.cfm?id=1039535 https://queue.acm.org/detail.cfm?id=1039535
• movedx 7y ago
  > You're just a bunch of engineers who know the whole codebase inside out, you're pretty certain of what you're doing. In short, you're wizarding. If you grow big enough, this approach slows you down greatly, and you need to switch to engineering. I've never heard of this before... I love it. Thanks for bringing this up.
• heartbreak 7y ago
  This is similar to Martin Fowler’s Design-Stamina Hypothesis [0]. [0] https://martinfowler.com/bliki/DesignStaminaHypothesis.html https://martinfowler.com/bliki/DesignStaminaHypothesis.html
• ken 7y ago
  > When you're a small startup, what matters is the expressiveness of your language, and the ability do do a lot of things very very quickly. Type safety, performance, readability, those things don't matter. I’ve never worked on a program so small that readability didn’t matter. I consider it a crucial ingredient of expressiveness and development speed. Though your perspective could explain a few of the more atrocious code bases I’ve seen.
  • jacquesm 7y ago
    During exploratory programming I don't care at all about readability, just about find a path - any path - to something that works. As soon as I have that readability starts to matter and the first order of battle is then to refactor out all the dead ends and to make the whole thing look good. That's because the project now has long term perspective.
• choiway 7y ago
  I like the way you characterize this but what on your thoughts on why you can't be a wizard with a typed language? Seems to me that if you start with something like Go or Typescript you cover a decent middle ground of foregoing a lot of boilerplate while having code that you don't need to be a wizard to understand.
• DonaldPShimoda 7y ago
  > When you're a small startup, what matters is the expressiveness of your language, and the ability do do a lot of things very very quickly. Type safety, performance, readability, those things don't matter. You're just a bunch of engineers who know the whole codebase inside out, you're pretty certain of what you're doing. I'm not familiar with this use of the term "expressiveness". My understanding is that expressiveness (as per "On the expressive power of programming languages", Felleisen 1991 [0]) has to do with capabilities that a language has that separate it from another language. C is more expressive than Python in that it gives you direct access to memory management, whereas Python is more expressive than C in that it provides inheritance/OO. (These are just examples.) Type safety, performance, and readability are all wholly separate from expressiveness, I think. A language's type system and performance benchmarks have nothing to do with the expressive power of a language outright, and "readability" is entirely subjective to begin with. So: would you mind elaborating on what you mean, exactly, by "expressiveness of [a] language" here? --- In fact, most of what you (and the linked article) are talking about has to do with the dynamic/static spectrum, not this "wizarding/engineering" spectrum you've coined (though I do kind of like the idea of that for discussing development methodologies). The article is all about how the dynamically-typed nature of Python allowed for rapid iteration at the beginning of the Instagram project, but has since hindered further progress as they've grown larger. But now they feel they can't just rewrite it all in a statically-typed language because of the engineering overhead involved. On this note, I want to go to your last point: > I wish there was a language that let you move gradually from one end to the other, exactly when you need to. With regard to the dynamic/static distinction, there are languages that allow you to move "gradually from one end to the other", and they are (aptly) called gradually-typed languages. Gradual typing was invented by Jeremy Siek and his PhD student, Walid Taha, back in the mid-2000s at Indiana [1]. In this discipline, you can have a statically-typed codebase with local dynamically-typed regions. You get all of the static guarantees for everywhere that they can be made, and dynamic regions impose runtime checks to ensure consistency. (This connects closely to contracts, which are primarily worked on by Robby Findler at Northwestern, I think.) Unfortunately (to me), it seems like a lot of these languages are implemented in terms of existing dynamically-typed languages. For example, Sam Tobin-Hochstadt (Indiana) created Typed Racket, which is (of course) built upon Racket but provides a gradual typing discipline. Wherever possible, static types are checked, and everywhere else utilizes contracts to guarantee runtime consistency. Anyway, all this is to say: the technology exists, technically, but is in its infancy. There's no doubt it'll be some time before it sees widespread use throughout industry. Sam wrote up a brief overview for the SIGPLAN Perspectives blog recently, if you're interested [2]. [0] https://www.sciencedirect.com/science/article/pii/016764239190036W https://www.sciencedirect.com/science/article/pii/0167642391... [1] https://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typing/ https://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typin... [2] https://blog.sigplan.org/2019/07/12/gradual-typing-theory-practice/ https://blog.sigplan.org/2019/07/12/gradual-typing-theory-pr...
• andybak 7y ago
  And the worst thing is using languages/libraries/frameworks that presume everyone needs engineering when you need to wizard. There's two many people that have swallowed SOLID whole and can no longer see good engineering as a trade-off against other factors. For example, being strict about having the smallest possible public API and making most methods private protects me from future breakage that might never be an issue (I might never upgrade) but forces me copy/paste vast globs of your code into my own if I need access to something you didn't anticipate. (and that's assuming I have access to your source. Worst case is that I have to reimplement things that already exist in the code I'm interfacing with) Python got this right. Private methods are a weak or strong hint that you might want to think twice before calling them. But you're the boss at the end of the day.
  • pytester 7y ago
    >And the worst thing is using languages/libraries/frameworks that presume everyone needs engineering when you need to wizard. I think this is why it's easy to point a thousand things built in python which people use every day (like instagram), while in, say, haskell, there are barely a handful (pandoc, facebook spam filter, etc.).
• deleted 7y ago
  [deleted]