Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Near Future of Programming Languages [pdf]

dev.stephendiehl.com

Post reply on HN
Print view View original

271–280 of 306 posts

Re: Near Future of Programming Languages [pdf]

#271

Post by Chris_Newton »

flavio81 wrote: post #267
SiVal wrote: post #260

Earlier quoted context omitted.

Are there any languages you know of that are somewhat close to what you describe?

Yes, they exist and have been used for decades; two well known examples are Common Lisp and Scheme. For example you can do functional, imperative and OO programming in Common Lisp, and it brings extensive features for working in all these three paradigms. More recent examples, Racket and Julia.

There are several reasonably well-known languages that bridge the functional and imperative worlds in one way or another. However, I’m looking for more than just that. In particular, I’d like to have good tools for both imperative/stateful and functional/data-transforming coding, but all within a safe, structured environment in terms of effects/external interactions/observable behaviour.

Now, I am by no means a Lisp expert, so it’s entirely possible that I’m completely unaware of something here. However, I’ve yet to encounter much of an effect system in any flavour of Lisp. Indeed, it’s hard to see how the sort of explicit visibility and control of effects that I’d find useful could be achieved in a language with primarily dynamic typing using any of the approaches I’ve encountered so far.

Re: Near Future of Programming Languages [pdf]

#272

Post by boznz »

pjmlp wrote: post #94
PaulRobinson wrote: post #89

Earlier quoted context omitted.

I disagree with a few of your thoughts, but they're good thoughts! * Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry. One thing I've noticed (and I say this as a guy who wrote Ruby for 10+ years), is that type safety is becoming a hugely desired feature for developers again. * WYSIWYG web de…

> WYSIWYG web design (a la Dreamweaver) died off .... Which is why what we actually need is a la Delphi

Funnily enough I was looking at the title and just thinking in 25 years time I will still be programming in the same three languages C, Pascal/Delphi and SQL I learnt 25 years ago.

Re: Near Future of Programming Languages [pdf]

#273

Post by boznz »

pron wrote: post #234
lmm wrote: post #228

Earlier quoted context omitted.

> That is a very powerful statement, and I'd like to know why you'd think that. I would even like to know what makes you think that any language (never mind which) can make such an impact, even though we've seen nothing of this sort. I think we have; I think we've seen dramatically accelerating programmer productivity. I think language improvements compound heavily: if a language is slightly more efficient in the sma…

> I think we've seen dramatically accelerating programmer productivity. Really? I think that the change that has contributed to the lion's share of that boost has nothing to do with language features, and has everything to do with the availability of open-source libraries. The other major contributions have been the widespread adoption of automated unit tests -- also not a language feature, and the practicality of GC…

Agree 100%

Re: Near Future of Programming Languages [pdf]

#274

Post by pron »

noam87 wrote: post #262
pron wrote: post #250

Earlier quoted context omitted.

I think they're better largely because I'm more aesthetically drawn to them (so I will be biased, but no more so than the author, who also only mentions techniques he's aesthetically drawn to), but also because I think they have shown more success in practical industry use. For programming interactive systems, a very interesting approach which has been quite successful in realtime software and hardware systems, is sy…

Eve looks interesting, thanks I'll try it out. (And the detailed response.) Most of my programming is in the domain of "take some data, do stuff to it, produce an output" and my experience with Idris so far is very positive -- more so than Haskell (which I admittedly gave up on early on), the language does feel ergonomic, and like the type system is "guiding me" rather than getting in the way. I also find its approac…

I don't doubt that Idris is a fine language or that some people will love it, even though personally I'm not drawn to pure-FP; I do doubt its revolutionary bottom-line impact.

Re: Near Future of Programming Languages [pdf]

#275

Post by aryehof »

Myrmornis wrote: post #253
aryehof wrote: post #227

Earlier quoted context omitted.

There are some that can walk up to a white-board and (repeatedly and predictably) create a domain object model representing complex business requirements. One directly convertible to code. They can do this because they know a set of higher order patterns, beyond just a knowledge of "objects" and "classes". Beyond just a design approach of identifying classes as the "nouns" in a problem domain. These higher order patt…

OK, so that covers data modeling, and I agree with you that that is a rare and yet critical skill. But if I'm envisioning correctly the talents that you're describing, that still leaves a large amount of concurrent/asynchronous logic undescribed/undesigned. I expect you know what I mean; maybe a jumble of words like "multiple superimposed event-driven parallel state-machines" gives the idea. You mention a "domain obj…

I am talking about a domain model of the problem under consideration. That model is the same thing from analysis/design to code. It is independent of technical concerns and plumbing. Independent of a particular interface or mechanism for persistence. I'm talking about using standard programming language features, rather than yet another (diagrammatic) language that requires translation to executable code.

Those technical concerns are dependent on the non-functional requirements of the particular required solution. This includes aspects of concurrency.

I suspect your interested in a "framework" that supports both problem domain modeling and specific technical circumstances?

Re: Near Future of Programming Languages [pdf]

#276

Post by andreaferretti »

Chris_Newton wrote: post #270
SiVal wrote: post #260

Earlier quoted context omitted.

Are there any languages you know of that are somewhat close to what you describe?

None of the programming languages that I know well myself provides the sort of balance I’d like to see between: (a) strong visibility of and control over effects, (b) an emphasis on powerful tools to represent and manipulate data, and (c) straightforward imperative/stateful aspects when required. Of course that isn’t to say that no such language exists, but if it does then sadly I have yet to become aware of it. New…

You may want to try Nim. It is an imperative language with meta programming capabilities, some functional features and an effect system

Re: Near Future of Programming Languages [pdf]

#277

Post by nadagast »

js8 wrote: post #104

I would love to see programming as a dialogue between user and computer (programmer and compiler). For example: Compiler would infer the types, and the programmer would read it and say, oh, I agree with this type, but I disagree with this type, that's perhaps wrong, this should be rather that type. Then the compiler would infer types again, based on programmer's incremental input. Data structure selection. Programmer…

I've been thinking a lot about nearly these exact same things. We desperately need better ways to deal with derived textual data. Why do we make the programmer guess which data structure will work best for a particular task, when we could easily try it each way and record the performance, and pick the best? A big part of the reason must be that we have no good strategy for storing that data and making that choice in an ongoing and living way, inside of a code repository. We suck at dealing with derived data on the meta layer above our programming languages.

Email me at glmitchell[at]gmail if you want to chat more about this.

Re: Near Future of Programming Languages [pdf]

#278

Post by fnord123 »

shalabhc wrote: post #257
fnord123 wrote: post #207

Earlier quoted context omitted.

There is a dichotomy between sealed programs and evolving programs. Evolving programs like Smalltalk or REPLs are great for exploratory work. Almost everyone wants sealed programs for systems to work reliably. This runs along the lines of Ousterhout's dichotomy as well - scripting vs systems languages. The engineering break through will be when we have a scripting/evolving system that can be more easily distilled int…

Do you see this as a useful dichotomy? In reality no system is truly sealed - it's just temporarily sealed between evolution steps, no?

I do find it a useful dichotomy because I work with people who evolve their code and wonder why I get my back up about monkey patching (because it's often my job to turn research or prototype quality code into reliable code).

If you've ever had to make another person's research or prototype quality code more robust it can be easy to wonder how on Earth they work the way they do. Having this dichotomy in mind makes it easier to have more sympathy.

It works both ways. Researchers need to understand why platform development moves so slow. This dichotomy helps reason about it.

But you're right, between evolution steps the system is not sealed. That's a concern and why projects like Debian are keen to have reproducible builds. It's also a big part of why containerization is becoming so popular.

Re: Near Future of Programming Languages [pdf]

#279

Post by tom_mellior »

js8 wrote: post #104

I would love to see programming as a dialogue between user and computer (programmer and compiler). For example: Compiler would infer the types, and the programmer would read it and say, oh, I agree with this type, but I disagree with this type, that's perhaps wrong, this should be rather that type. Then the compiler would infer types again, based on programmer's incremental input. Data structure selection. Programmer…

> Programmer would say I want a sequence here. The compiler would say, I chose a linked list representation. The programmer would look over it, and disagree, saying, you should put this into an array.

To some extent, this is the promise of object-oriented programming, that in this particular instance has failed a bit in mainstream languages. It's true that in, say, Java, you have to massively refactor your code to switch between arrays and linked lists, because you use different syntax ([] vs. method calls) to access elements. It could be a bit better in C++ due to operator overloading; you could hide your actual container type behind a typedef, and as long as both container type A and container type B support the same operations with [] that you actually use, you can freely switch between them.

In Smalltalk, every container class derives from a single Collection class, and they have very very similar APIs. There you can, to a large extent, just program against the Collection API and not care much about the actual type of collection you have in your hand. You still have to choose one! The compiler won't do it for you, not in the way you envision. But the idea is that if you program against the generic API, then profile/benchmark your code, it should suffice to change a single line of the program to try a different representation to compare against it. (Of course some things won't work. You can't index into a set.)

Other dynamic languages should be similar, Python for example. But I think you have to work harder to achieve full genericity.

Post reply on HN