5 ms·

The “ Some safe and some bold predictions” comment is almost exactly my view on how programming should evolve. (functional, reactive, going toward dependent typ

The “ Some safe and some bold predictions” comment is almost exactly my view on how programming should evolve. (functional, reactive, going toward dependent types etc ) Interesting how in 2012 it was already so clear! I think mostly we do have gone in that direction, even if probably even slower than the (already cautious) commenter predicted. Honest question: why are we as a community so slow at evolving a good, solid programming environment? I get that each time a new language is introduced, porting over all the existing code + training the people is an immense task. But this is _exactly the problem_, right? Why aren’t we able to stop for a while and sort out once and for all a solid framework for coding? It’s not a theoretical ideal: I’m very convinced that the dumb piling up of technologies/languages/frameworks that we use now is significantly slowing down the _actual daily work_ we do of producing software. Definitely >>50% of my time as a programmer is spent on accidental complexity, that i know for sure. It’s very practical: at this point this whole thing simply feels like very bad engineering, tbh?

dgb23 5y ago
There are many different types of programming. For example there is an increasing amount of people who program but do not have programming related job titles. - A designer might use HTML/CSS/JS directly or with "low code" tools (AKA graphical IDEs, they are still essentially programming) to implement frontends or a bit of scripting to automate stuff in their Adobe tools. - An analyst might use Excel (a programming environment) or SQL or some hybrid tool. - Mathematicians and scientists are increasingly programming. - An electrical technician or engineer programs their installations. - And so on... There isn't one paradigm or even a set of paradigms that fits them all. Some languages are deliberately straight forward and provide minimal abstractions, other languages have strong runtime guarantees, others enable flexible, composable abstractions. I think programming will become even more diverse in the future.
tapas73 5y ago
My take on this: 1. Societal issues. Microsoft wanted Java they could control and change. C# it is then. Google is moving away from java to kotlin, because of disagreements with Oracle. 2. Wish of different trade offs. fast-to-learn vs feature-full vs ease-of-use vs configurability vs portability vs speed vs safety vs developer friendly vs user friendly vs admin friendly vs development-speed vs program corectness. 3. Low proof-of-concept cost. If some lib involves lot of boilerplate for my usecase, it is easy to create my own improved version and feel the sense of achievement (my version might be just a wrapper at first, but the gate have opened) 4. Reduction-of-programing-worlds-complexity is at the bottom of everybodies priority lists.
- kaba0 5y ago
  Google moving away from Java has nothing to do with Oracle. That lawsuit was about an old Sun license of Java that was thought to be hurt by Google. Since then, Java was completely open-sourced, having the same license as the Linux kernel, so there is nothing stopping android from using it. The preference for kotlin comes from the fact that Android’s Java is barely at OpenJDK’s Java 8 versions, making syntactic sugars all that much more important there.
- still_grokking 5y ago
  > Google is moving away from java to kotlin, because of disagreements with Oracle. Java and it's VM are OpenSource. So that argument doesn't make any sense. Also I don't think Google would, or even could, move away form one of their primary languages. Kotlin on the other hand is only a significant trend in Android development, and it will get dropped like a hot potato in favor of Dart as soon as Fuchsia arrives as Android successor, I guess. Kotlin has a problem: It tries to be "the better Java", but Java is picking up (slowly) all the features. The space for a significantly more powerful JVM language is already taken by Scala. So in the long run there won't be much space for Kotlin left: As soon as Java will get "more modern Features" Kotlin will have a hard time to compete. As likely mostly only syntax differences will remain.
  - deleted 5y ago
    [deleted]
  - throwaway383838 5y ago
    > Kotlin on the other hand is only a significant trend in Android development, and it will get dropped like a hot potato in favor of Dart as soon as Fuchsia arrives as Android successor, I guess. Do you have any idea just how much there's Android/Java/Kotlin code now? > Kotlin has a problem: It tries to be "the better Java", but Java is picking up (slowly) all the features. 2016 called. Wants your opinion back. Kotlin is sooo much more now than "better Java", it is a Multiplatform, efficient and pragmatic language that is just pleasant to work with, unlike even modern Java. It has first party support for iOS, Android, desktop and JS. It has modern Multiplatform GUI framework that rivals React and Flutter. It has countless syntactic features and built-in null safety. Java will be forever stuck in server and niche products like Intellij.
still_grokking 5y ago
> The “ Some safe and some bold predictions” comment is almost exactly my view on how programming should evolve. (functional, reactive, going toward dependent types etc ) Interesting how in 2012 it was already so clear! Given that languages used broadly in the industry are lacking behind research 20+ years that's not a good prediction. It's just the way things are going. BTW: There's still no mainstream language with full dependent typing… (I count Haskell as mainstream; Scala seems closest¹ but still a long way to go). Actually people are already so overwhelmed by all that really old stuff coming now to languages that some of them resort to even much more basic approaches on the level of the 70'ies, like Go, thinking programming is otherwise "too complicated". To add on that: I don't think "the average dude" will ever use for example depended types even they would appear in some broader used language. My guess for the future is more that we will see a kind of split between a big group of people using advanced low-code like tools for programming day to day things and data exploration, and some much smaller group of "experts" doing the "hard things" needed to make those tools work. On the one hand side this will bring programming further "to the masses". But on the other hand side the hard parts will not only remain, they will get even harder and much less approachable by arbitrary people. ¹ https://arxiv.org/abs/2011.07653 https://arxiv.org/abs/2011.07653
- qsort 5y ago
  > Given that languages used broadly in the industry are lacking behind research 20+ years This is obviously true in abstract, but the real breakthrough happens when you make those concepts ergonomic for the working developer. The theory behind dependent types is well established, but I can't really write my next project in Idris, can I? Similarly, there was a time when C was the only sensible choice to write anything non-academic, non-toy. It's not like people didn't know about OOP or functional programming back then, but it wasn't a realistic possibility. Or parametric subtype polymorphism, also known by its common name "generics". The concept has been around at least since the 70s, C++ templates weren't widely used before what, 1990? > My guess for the future is more that we will see a kind of split between a big group of people using advanced low-code like tools for programming day to day things This has arguably already happened, we call them data scientists. Many of them are technical and have some light scripting skills but they couldn't be put to work on, say, your average backend project. Obviously this is a gross generalization, titles mean literally nothing, I'm pretty sure there exist data scientists that kick ass at coding.
skohan 5y ago
Reactive is a mistake. It's a tool for a specific job, sure, but it's too big and opinionated of an abstraction to use it everywhere. The future of programming should be reality based. > Why aren’t we able to stop for a while and sort out once and for all a solid framework for coding? There's never going to be one "solution" here. There will always be tradeoffs depending on the constraints of a given domain or problem space. One-size-fits-all solutions end up not being great for anything, since they have to make so many compromises. Also great tools are made through solving real problems. If we just went to plato's heaven and dreamed up a "perfect" programming environment, we would end up with something which solves our problems in theory. But the issue with this is that our problems don't exist in theory, they exist in reality.

dgb23 5y ago

There are many different types of programming. For example there is an increasing amount of people who program but do not have programming related job titles. - A designer might use HTML/CSS/JS directly or with "low code" tools (AKA graphical IDEs, they are still essentially programming) to implement frontends or a bit of scripting to automate stuff in their Adobe tools. - An analyst might use Excel (a programming environment) or SQL or some hybrid tool. - Mathematicians and scientists are increasingly programming. - An electrical technician or engineer programs their installations. - And so on... There isn't one paradigm or even a set of paradigms that fits them all. Some languages are deliberately straight forward and provide minimal abstractions, other languages have strong runtime guarantees, others enable flexible, composable abstractions. I think programming will become even more diverse in the future.

tapas73 5y ago

My take on this: 1. Societal issues. Microsoft wanted Java they could control and change. C# it is then. Google is moving away from java to kotlin, because of disagreements with Oracle. 2. Wish of different trade offs. fast-to-learn vs feature-full vs ease-of-use vs configurability vs portability vs speed vs safety vs developer friendly vs user friendly vs admin friendly vs development-speed vs program corectness. 3. Low proof-of-concept cost. If some lib involves lot of boilerplate for my usecase, it is easy to create my own improved version and feel the sense of achievement (my version might be just a wrapper at first, but the gate have opened) 4. Reduction-of-programing-worlds-complexity is at the bottom of everybodies priority lists.

kaba0 5y ago
Google moving away from Java has nothing to do with Oracle. That lawsuit was about an old Sun license of Java that was thought to be hurt by Google. Since then, Java was completely open-sourced, having the same license as the Linux kernel, so there is nothing stopping android from using it. The preference for kotlin comes from the fact that Android’s Java is barely at OpenJDK’s Java 8 versions, making syntactic sugars all that much more important there.
still_grokking 5y ago
> Google is moving away from java to kotlin, because of disagreements with Oracle. Java and it's VM are OpenSource. So that argument doesn't make any sense. Also I don't think Google would, or even could, move away form one of their primary languages. Kotlin on the other hand is only a significant trend in Android development, and it will get dropped like a hot potato in favor of Dart as soon as Fuchsia arrives as Android successor, I guess. Kotlin has a problem: It tries to be "the better Java", but Java is picking up (slowly) all the features. The space for a significantly more powerful JVM language is already taken by Scala. So in the long run there won't be much space for Kotlin left: As soon as Java will get "more modern Features" Kotlin will have a hard time to compete. As likely mostly only syntax differences will remain.
- deleted 5y ago
  [deleted]
- throwaway383838 5y ago
  > Kotlin on the other hand is only a significant trend in Android development, and it will get dropped like a hot potato in favor of Dart as soon as Fuchsia arrives as Android successor, I guess. Do you have any idea just how much there's Android/Java/Kotlin code now? > Kotlin has a problem: It tries to be "the better Java", but Java is picking up (slowly) all the features. 2016 called. Wants your opinion back. Kotlin is sooo much more now than "better Java", it is a Multiplatform, efficient and pragmatic language that is just pleasant to work with, unlike even modern Java. It has first party support for iOS, Android, desktop and JS. It has modern Multiplatform GUI framework that rivals React and Flutter. It has countless syntactic features and built-in null safety. Java will be forever stuck in server and niche products like Intellij.

still_grokking 5y ago

> The “ Some safe and some bold predictions” comment is almost exactly my view on how programming should evolve. (functional, reactive, going toward dependent types etc ) Interesting how in 2012 it was already so clear! Given that languages used broadly in the industry are lacking behind research 20+ years that's not a good prediction. It's just the way things are going. BTW: There's still no mainstream language with full dependent typing… (I count Haskell as mainstream; Scala seems closest¹ but still a long way to go). Actually people are already so overwhelmed by all that really old stuff coming now to languages that some of them resort to even much more basic approaches on the level of the 70'ies, like Go, thinking programming is otherwise "too complicated". To add on that: I don't think "the average dude" will ever use for example depended types even they would appear in some broader used language. My guess for the future is more that we will see a kind of split between a big group of people using advanced low-code like tools for programming day to day things and data exploration, and some much smaller group of "experts" doing the "hard things" needed to make those tools work. On the one hand side this will bring programming further "to the masses". But on the other hand side the hard parts will not only remain, they will get even harder and much less approachable by arbitrary people. ¹ https://arxiv.org/abs/2011.07653 https://arxiv.org/abs/2011.07653

qsort 5y ago
> Given that languages used broadly in the industry are lacking behind research 20+ years This is obviously true in abstract, but the real breakthrough happens when you make those concepts ergonomic for the working developer. The theory behind dependent types is well established, but I can't really write my next project in Idris, can I? Similarly, there was a time when C was the only sensible choice to write anything non-academic, non-toy. It's not like people didn't know about OOP or functional programming back then, but it wasn't a realistic possibility. Or parametric subtype polymorphism, also known by its common name "generics". The concept has been around at least since the 70s, C++ templates weren't widely used before what, 1990? > My guess for the future is more that we will see a kind of split between a big group of people using advanced low-code like tools for programming day to day things This has arguably already happened, we call them data scientists. Many of them are technical and have some light scripting skills but they couldn't be put to work on, say, your average backend project. Obviously this is a gross generalization, titles mean literally nothing, I'm pretty sure there exist data scientists that kick ass at coding.

skohan 5y ago

Reactive is a mistake. It's a tool for a specific job, sure, but it's too big and opinionated of an abstraction to use it everywhere. The future of programming should be reality based. > Why aren’t we able to stop for a while and sort out once and for all a solid framework for coding? There's never going to be one "solution" here. There will always be tradeoffs depending on the constraints of a given domain or problem space. One-size-fits-all solutions end up not being great for anything, since they have to make so many compromises. Also great tools are made through solving real problems. If we just went to plato's heaven and dreamed up a "perfect" programming environment, we would end up with something which solves our problems in theory. But the issue with this is that our problems don't exist in theory, they exist in reality.