Just curious where does Elixir fall in this scheme of things? Any experienced devs who could give a qualified answer, please?
Near Future of Programming Languages [pdf]
91–100 of 306 posts
Re: Near Future of Programming Languages [pdf]
#92My thoughts are that we don't really need more languages. Arguably we don't need better ones either, because they aren't the problem in general computing. Instead we need better design paradigms that better let us model complex requirements and systems into code. Let's have new languages that then support those paradigms. We continue to struggle abstracting complex problems using functional decomposition, structured…
> A focus on programming languages in my opinion, masks the real issues we face.
Indeed, major problems of programming languages can hardly be solved in the area of programming languages itself as it is being done now.
I would say that one needs a new programming or computing model so it is not about languages. At least it is my conclusion after 10+ years of research and attempts to develop such a new programming paradigm. And although I have quite significant progress (concept-oriented programming), the more I do and the deeper I go, the more fundamental problems I meet. And these problems are not about programming languages at all. It is more about "how a system works", "what is a system", "what is computing" etc.
Re: Near Future of Programming Languages [pdf]
#93Earlier quoted context omitted.
A quick Google didn't supply any supporting evidence. Do you know of a reference?
That that's how it's pronounced in Australia? I don't know of any specific reference, it's just what I know from being familiar with Australian pronounciation (it's where I was born and live). BTW, in case there has been some confusion here, since the topic was how things were said, I have been assuming this is what the person I was replying to was talking about, not spelling.
Ah thanks, I thought you were saying it was spelled with "ou".
Re: Near Future of Programming Languages [pdf]
#94Things to think about for the near future of programming languages: - The borrow checker in Rust is a great innovation. Previously the options were reference counts, garbage collection, or bugs. Now there's a new option. Expect to see a borrow checker in future languages other than Rust. - Formal methods are still a pain. The technology tends to come from people in love with the theory, resulting in systems that are…
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
Re: Near Future of Programming Languages [pdf]
#95Things to think about for the near future of programming languages: - The borrow checker in Rust is a great innovation. Previously the options were reference counts, garbage collection, or bugs. Now there's a new option. Expect to see a borrow checker in future languages other than Rust. - Formal methods are still a pain. The technology tends to come from people in love with the theory, resulting in systems that are…
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…
> Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language
Everybody is everybody who has used other languages intensively or is into programming languages or, the most negative parties against JS, people who are into formal methods. But 'everybody'; I get often downvoted to hell for being negative on JS on Reddit. And i'm not using a baseball bat; i'm subtle about it as I don't care for language wars. Use what you want, but please don't say it's the best thing to happen to humanity. But no; 'everybody' (as in headcount) thinks it is the best thing that happened to humanity and that other languages should die because you can write everything in JS anyway.
Re: Near Future of Programming Languages [pdf]
#96Looking at the 2010 Haskell report: most of the committee members come from 'Academia':
https://www.haskell.org/onlinereport/haskell2010/haskellli2....
How is it an 'industrial' language? Haskell is the main 'academic' language for a branch of Functional Programming.
'industrial' is just another weasel word.
Re: Near Future of Programming Languages [pdf]
#97Earlier 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
Interesting. Can you elaborate more?
Re: Near Future of Programming Languages [pdf]
#98> Will we just be stuck in a local maxima of Java for next 50 years?
1. Yes, if the extent of the imagination is languages like Idris and ideas like effect systems, that follow a gradient descent from Java, and always in the same direction: being able to express more constraints. What you get "for free" from such languages may not be significant enough to justify the cost of adoption, and the valuable stuff you can get is not much easier than the options available today, which are too hard for anyone to take. If you were to consider truly novel languages that think out of the box (e.g. Dedalus/Eve) then maybe one will stick and make an actual impact rather than just a change in fashion.
2. How do you even know that we can do much better? NASA engineers may not like it, but they don't complain that we're "stuck" at sub-light speeds. Maybe Brooks was right and we are close to the theoretical limit (that we know must exist).
> We talk about languages as a bag of feelings and fuzzy weasel words that amount to “It works for my project”.
Can you find another useful way, available to us today, of talking about languages?
> “Use the right tool for the job” Zero information statement.
That's right, but it's not a dumb cliché so much as it is a tool we've developed to shut down religious/Aristotelian arguments that are themselves devoid of any applicable, actionable data. One, then, is often confronted with the reply, "but would you use assembly/Cobol?" to which the answer is, "of course, and it's not even uncommon, and if you don't know that, then you should learn more about the software industry before giving any more Aristotelian arguments."
Re: Near Future of Programming Languages [pdf]
#99One area I haven't seen any good solutions for is the interleaving of tests with production code. I think we need better ways to express tests without cluttering the production code and excessive mocking. What I'd like to do, and really can't in any language/tooling that I know of, is to extract some arbitrary subset of the code and surround it with tests or a test harness. I'd also like to specify various injection…
William Byrd's work in program synthesis is an interesting take on this, where an IDE can, guided by test cases written for a function, actually auto-complete code itself whilst writing the function, or tell the programmer when they have something wrong by violating a test case. Of course it is impractical right now, but a good step nonetheless.. It (Barliman) is demoed near the end of this video: https://youtu.be/Oy…
This is indeed an extremely interesting approach.
It was pioneered in the context of logic programming and Prolog by Ehud Shapiro in his 1982 PhD thesis "Algorithmic Program Debugging". The thesis was published as an ACM Distinguished Dissertation by MIT press and is available online from:
http://cpsc.yale.edu/sites/default/files/files/tr237.pdf
Together with Leon Sterling, Ehud Shapiro later wrote a very important introductory Prolog book called "The Art of Prolog".