3 ms·
React might go away, but javascript/typescript will probably be a good bet for the next 10 years (who knows beyond that). I'd like to think that people will co
by mattlondon 7y ago
React might go away, but javascript/typescript will probably be a good bet for the next 10 years (who knows beyond that).
I'd like to think that people will come to their senses about Python and use sensible languages for ML + data once they relearn all the problems that software engineers learnt about it all that time ago (fast development != reliable/maintainable development, fast development != easily-scaled development with teams of 10+ etc)
- mrlala 7y ago>but javascript/typescript will probably be a good bet for the next 10 years Honestly how is javascript (and thus typescript) ever going away at this point? I honestly mean _ever_. Like until the day I die. Almost the entire web is using it. Frameworks like React, Angular, Vue have made it so I basically don't care that much about javascript. Most of my code is server-side and the client is largely handled by Angular as a framework so the amount of JS I have to write in my angular components is so minimal. All that being said, I personally am not a fan of javascript.. at all. The learning curve to know what's going on is horrific in my opinion, and code is not meant to be written clearly but have a small footprint which is terrible. It's too flexible.. though typescript has solved 90% of that. Even if something like Blazor completely transforms the web, it seems like there will ALWAYS be the case for streamlined simple sites that only need very simple javascript transformations.. Anyway- unfortunately I think javascript is here for the next billion years!
- mpartel 7y agoWebAssembly has some hope of changing how browsers are programmed, but you're probably right that JS will live on for many human generations as a legacy tech at least.
- Roboprog 7y agoContrarian, albeit minority, view: I really like ECMAScript. It’s not a weaker Java, it’s better. I’ve been programming since the 80s. We had OOP shoved down our throats in college (CSU), with FP downplayed due to the runtime cost. Things have changed, and I want to move on. I wish there was demand for ClosureScript. TypeScript has no support for partial function application and currying, unless it was added very recently.
- M5x7wI3CmbEem10 7y agoWhat are the problems with Python? I’m an undergrad student that just wants a job. Programmed for a year in Java, but heard that I should be transitioning to Python if I want to work with the big ML libraries such as PyTorch, PySpark, NumPy, Pandas, etc.
- yowlingcat 7y agoI think you might be conflating good general software engineering practices with language choice. Remember that the current dominant social network of our time (Instagram) built and scaled just fine off of Django + Postgres and a relatively small engineering team -- you can write poor code in Python just like you can in Java, and you can write good code in either one.
- ptx 7y agoOuch, those are the arguments people usually bring forward to defend PHP – strange to hear them applied to Python. While I agree that good software engineering practices makes the real difference, it's not the only thing that matters. There are better languages and worse languages. While you can apply good practices and successfully build good stuff using a language designed in 10 days (or a language that evolved accidentally from a templating system), those practices will have to work a lot harder than they would if you had used a better language. Python has a split user base, where roughly half consists of data scientists who use it by necessity and might not always apply software engineering best practices, but many people in the other half use it by choice because it's a nice language.
- yowlingcat 7y agoWell, are you trying to say that PHP is impossible to use properly? It's not exactly the first tool I'd look for, but it's clearly possible to use at scale if we look at what Facebook did with it. I have to completely disagree with you. There is no such thing as better or worse languages in a vacuum. Languages exist in an ecosystem that you use to build things using them. Most best practices you apply as a software engineer are reasonably language agnostic. On the other hand, tooling, libraries, frameworks -- many of these things cannot easily ported over from one language to another, and moreover have taken many billions of dollars or man hours of effort from many people before us to get to where they are. For what it's worth, you don't really make any arguments as to what makes a language better or worse, and you don't really make any arguments that "those practices will have to work a lot harder than they would if you had used a better language" -- for whom? I have worked with hundreds of talented engineers in my life building codebases that have lasted the test of time and I have never once ran into one who had difficulty making a quality codebase using whatever language they ran into. Blaming a language for poor code is a crutch, and drawing a correlation between code quality and language is dubious. Which more likely has an outsize effect on codebase quality, that the organization that wrote the code, or the language itself? I'll go for humans as the weak link every time.