almost excusively javascript frameworks
What will programming look like in 2020? (2012)
111–120 of 151 posts
Re: What will programming look like in 2020? (2012)
#112I had a play around with Logo the other day. In the end I decided to dive too deeply into it, but I came away thinking that there is basically nothing wrong with the language. It was invented in 1967. 1965! Yet it has everything "there". I think there's even a university professor who teaches Logo to undergraduates, too, claiming it is much better than Pascal. Pascal. That could be used as a systems programming langu…
I also like MX bust only use it to handle constraints and find a suitable use of a chip resources. After I have all resources planned it's CMSIS all the way, not that complex.
Re: What will programming look like in 2020? (2012)
#113http://lambda-the-ultimate.org/node/4655#comment-73772 > ... the beginnings of intelligent ... assistants in our IDEs ... specialize (sic) in ... C/C++, Java, Mobile. They will have intimate knowledge of common APIs ... trained on tens of thousands of code projects pulled from the open repositories across the web (google code, github, bitbucket,...). In addition to having 'read' more orders of magnitude more code the…
Cherry picking only the accurate prediction makes it seem like the predictor is really good! Look at the rest of that quote: > The human, computer pair, will also interactively suggest, confirm and fine tune specifications of mathematical properties and invariants at points in the the program. That hasn't happened and as far as I am aware, is not even close. > This will help the computer assistant to not only better…
> That hasn't happened and as far as I am aware, is not even close.
Isn't that just the Rust borrow checker?
Re: What will programming look like in 2020? (2012)
#114Earlier quoted context omitted.
Writing scrapers with it is also amazing. All from the puppeteer code, response interface and casting to a local class model. Very time saving indeed.
How close are you to being fully obsolete?
The correct response to becoming obsolete is to learn something new, not to fight the thing making you obsolete. Doing the latter is about as productive as yelling at the tide to not come in.
Re: What will programming look like in 2020? (2012)
#115Earlier quoted context omitted.
Rust’s type system is very close to Haskell’s and takes a lot of inspiration from functional programming. I’m not sure I’d call Rust mutable-first either. As for side-effects, I suspect the next leap in PL development will be an efficient algebraic-effects system with a good dev experience (or at least a trade-off so appealing it overcomes the necessary friction).
> Rust’s type system is very close to Haskell’s and takes a lot of inspiration from functional programming. Well… No. It misses some landmark features like HKTs, and it likely never won't get them. Inspiration? Sure. But what lang today doesn't take that? > I’m not sure I’d call Rust mutable-first either. So what do the affine types track? ;-) > As for side-effects, I suspect the next leap in PL development will be a…
Thing is, the constraints that make mutability and side effects "safe" are pretty much indistinguishable from functional programming. You can opt out of those in Rust via "internal mutability", but that comes with a corresponding increase in complexity.
Re: What will programming look like in 2020? (2012)
#116Earlier quoted context omitted.
Does anyone actually use Copilot day to day? How much time does it actually save?
I do every day. I code 5 times faster on problems several times harder. You also get good at 'using copilot' just like you can be 'good at googling'. So if you not already doing it. Start now. IMO. There's literally no point coding without it. You are completely wasting your time. However it has limits. It only helps you write code. Architecture is still down to you. If it could read your whole codebase rather than j…
> There's literally no point coding without it.
Except maybe that it is still not generally available.
Re: What will programming look like in 2020? (2012)
#117Earlier quoted context omitted.
> Leveraging the strengths of the computer and human will lead to an order of magnitude improvement in programmer productivity. Interactive testing will eliminate whole classes of logic bugs, making most non ui code correct by construction. I'd like to see evidence / experience reports backing up this part. Certainly Copilot exists, but what I've read about it is pretty mixed.
More like Brooks was the one being right (for like 3 decades now) with his ‘No silver bullets article’, in that we will not have another order of magnitude productivity change in programming after high level languages became a thing.
Brooks wrote "No Silver Bullet" in 01987. The examples of high-level languages he mentions in his paper are Ada, Modula (not sure whether the 01975 version or Modula-2), Simula-67, APL, Pascal, Smalltalk, Fortran, COBOL, PL/I, and Algol, and of these he thinks Ada is the most promising. Does his thesis hold up in the face of modern programming language advances?
I am not confident that there are programs I can write in Python, JS, or OCaml in one hour that nobody can write in Ada in ten hours, and programs in those languages in ten hours that nobody can write in Ada in 100 hours. I'm even less confident that they beat Smalltalk by as much. The exception is for very small programs: you can write things in Python in 5 minutes that nobody can write in Ada in an hour.
http://canonical.org/~kragen/sw/dev3/rpneact.py is maybe one example, which I wrote over the course of about 12 hours on January 2. It's a simple interactive calculator app that includes a general-purpose numerical equation solver; from the Python standard library it gets floating-point and complex arithmetic, regular expressions, and command-line editing. I don't think it would take me even as long as 120 hours to write it in C, which is roughly the same level as Ada but more painful to debug.
Similarly, http://canonical.org/~kragen/sw/dev3/lmu.py is a very limited MUD, where multiple users can connect, interact, and collaboratively build a textual world by creating rooms and other objects and setting their descriptions: sort of like a Wiki for interactive fiction, though without much richness of interaction. I wrote this between July 18 and July 24 last year, probably taking more than 20 hours in total. Writing it in C would have been slower but surely would not have taken 200 hours.
The main thing that's happened since 01987 is that computers have gotten a lot faster and bigger, so we can get by without as much attention to efficiency, and software libraries are also enormously more powerful. It's not that much easier now to write a SQL database than it was in 01987, but it's a hell of a lot easier to link in SQLite. It's not that much easier to write a regular expression matcher, but every modern language has one in the standard library already. Rendering Telugu text properly still involves a lot of hairy cases, but whether you're in a terminal or a browser, generally all you need to do is emit some UTF-8 bytes and you're golden.
Re: What will programming look like in 2020? (2012)
#118Earlier quoted context omitted.
> Rust’s type system is very close to Haskell’s and takes a lot of inspiration from functional programming. Well… No. It misses some landmark features like HKTs, and it likely never won't get them. Inspiration? Sure. But what lang today doesn't take that? > I’m not sure I’d call Rust mutable-first either. So what do the affine types track? ;-) > As for side-effects, I suspect the next leap in PL development will be a…
Thing is, the constraints that make mutability and side effects "safe" are pretty much indistinguishable from functional programming. You can opt out of those in Rust via "internal mutability", but that comes with a corresponding increase in complexity.
I don't think Rust can enforce referential transparency, nor does it have any focus on doing this manually. But I would say referential transparency is one the most important properties in functional programming, if not even the most distinguishing property.
Referential transparency is the one feature that makes reasoning about a program easy. You can think about referential transparent programs purely in the substitution model. You can move referential transparent expressions freely around as you please.
You can't think of a Rust program this way. It's inherently procedural.
Rust gets a lot of things quite right! But it's not a FP language. It's a better C. It's about shoveling bits and bytes around, as safely and efficient as possible.
Re: What will programming look like in 2020? (2012)
#119A couple small threads from back then: What will programming look like in 2020? - https://news.ycombinator.com/item?id=4962694 - Dec 2012 (3 comments) Ask HN: What will programming look like in 2020? - https://news.ycombinator.com/item?id=4931774 - Dec 2012 (12 comments)
> Unit testing will be built directly into languages as an intrinsic part, like compiler optimization or GC. Rust and Zig have this, right?
And Clojure!
Re: What will programming look like in 2020? (2012)
#120Rust in 2021 is basically the functional programming language this commenter was predicting: > I predict that functional programming will continue to gain ground as people discover the benefits of immutability and easy parallelism—but the functional language will not be Haskell, nor Scala, nor Clojure. At a guess, people will use something with: >Strong tooling and libraries >An accessible type system >Deterministi…
Rust is basically C++++ so I doubt it's what that commenter had in mind
Without a sequence point the result of that expression is undefined behaviour. Is that what you're trying to say about Rust?