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

Future of Programming Languages

c2.com

Post reply on HN
Print view View original

41–50 of 73 posts

Re: Future of Programming Languages

#41

Post by aikah »

david927 wrote: post #35

The future of programming should be one language for all layers of the stack, from the database to the model to the UI. I think that hints that it should be a form of declarative. And if it's declarative, it should be focused on managing state. And if it's a thin syntactical representation of its VM, instructions/code could be interpreted immediately at entry and be managed as state, so you wouldn't be working with a…

> The future of programming should be one language for all layers of the stack,

Programmers will never agree on what this language should be.Ever.

Because different tasks require different features,a language that tries to have all these features will be regarded as a mess,and disliked because of it.

Re: Future of Programming Languages

#43

Post by fsloth »

bane wrote: post #20

I think whatever the language of the future will be, it's likely that we're going to have to give up editing a bunch of text files. Much of modern programming these days is really about workflow of large teams. It'd be nice to have richer editing areas that allow for things like embedded diagrams and videos as comments, annotations, hypertext links out to documentation and from documentation into code, review comment…

I don't think tools are the problem, but rather the process is.

I think it's a false idea the dev envinronment should cater to all stakeholders and parties of the process. Maintainting the theory of the system is one of the most important things but I'm really sceptical an IDE and a tool based process can do it for us.

Yes, there should be preferably only one place and way to do a particular thing but that does not mean they have to be all bound to the same tool.

I.e. the algorithm development you described in your example used completely unnecessary gaps in the communication. If the expert and you had reserved time with a whiteboard or a google hang out and ironed out the bugs right there without this nonsense going through the formal code review process it would have been much easier for all parties.

If your boss wants to participate in the process and does not trust you enough that so he needs to doublecheck on every trivial detail I would call that micromanagement. Or, he can join in the discussion when it is going on if he can have valid input into it. Otherwise he should trust you to do the right thing, and if he wants to check up on things the revision history in the spec document (or just v1 and v2 of the spec) should be sufficient combined with the code changes.

If the boss wants to doublecheck on everything or the process requires that all communication related to code changes (including that quick discussion you had with the chief architect at the urinals) is stored then the problem is in the process that is too heavy with non-value-adding baggage and no tool can fix it.

Storage of the spec should be formalized, code review should be formalized, but not all communications and work related to data that is input into these system should and can be formalized.

I think the idea that tools will fix the process is a faulty idea - the process needs constant vigilance from human participants and tools can only facilitate it. Expert work can be incredibly value adding but it needs to be first and foremost built on trust between individuals and clear ownership of responsibilities. Final products can and need to be bound to formal constraints - the process needs rigor on an individual level but not anal-retentive overseeing over every minutiae.

Re: Future of Programming Languages

#46

Post by Dewie »

tomp wrote: post #34
overgard wrote: post #24

It seems like most languages are converging on a pretty standard feature set -- to the point where what "the" language is might not really matter because all its competitors will probably be roughly similar. I think we're at the point where almost every language will have: - Lexical scope & closures - Reflection - Functions-as-objects - The standard map/filter/reduce functions (sometimes under different guises and na…

They are all converging on these features because they have proven universally useful. But there is still a lot of work going on about other, new features. Some examples that interest me: - effects and exceptions - should we use monads (Haskell), macros (Rust), handlers (Eff, algebraic effects), extensible rows (Koka) - memory usage - how should we handle deallocation - using reference counting with infrequent GC (Py…

> - memory usage - how should we handle deallocation - using reference counting with infrequent GC (Python) or by being very careful (C++), using just GC and allocating freely (OCaml/Haskell, Java & Nim use "realtime" GC), using uniqueness semantics (Rust, ATS), using memory pools and great care (Objective C) - none of these approaches is perfect and optimal for all situations, and it's very frustrating that they don't really fit together

There is also ML Kit's usage of regions - I guess this is roughly the same std::Arena library in Rust.

Re: Future of Programming Languages

#47

Post by Dewie »

sanxiyn wrote: post #15

The most interesting language design I have seen is Noether. It is a language built on multiple layers. Inner layers guarantee more invariants (say, immutability) but forbids constructs you may want to use. Outer layers are more expressive but guarantee less invariants. Importantly, inner layers are not different languages but sublanguages of outer layers, and inner layers keep guaranteeing invariants even when used…

This also kind of sounds like the Hume programming language.

Re: Future of Programming Languages

#48

Post by Dewie »

webnrrd2k wrote: post #21
Guthur wrote: post #6

Earlier quoted context omitted.

They are called Domain Specific Languages (DSLs). And it can be done reasonably well today. Lisps are very good for producing DSLs; when you have macros you have very powerful control over the syntax and can therefore produce your own language within the language. The Common Lisp LOOP macro is a great example of power of macros; though in that case it is debatable whether it was used for good or bad.

I've just started looking at Rebol, and you may find it worth while -- it has a very interesting take on DSLs. http://www.rebol.com/

Rebol is one of the few languages where I was actually impressed by the code snippets that the introduction (that I read) had - they had to do with making simple GUIs for somewhat interesting/useful applications, and small, simple code for sending email. With most languages, the introductory code snippets are mostly just for showing the syntax and whatever simple function can be done in 2 lines instead of 5. But Rebol's code examples actually looked useful from the start.

I'll have to try it out some day. Alas, one of too many that I have to try out some day.

Re: Future of Programming Languages

#49

Post by david927 »

aikah wrote: post #41
david927 wrote: post #35

The future of programming should be one language for all layers of the stack, from the database to the model to the UI. I think that hints that it should be a form of declarative. And if it's declarative, it should be focused on managing state. And if it's a thin syntactical representation of its VM, instructions/code could be interpreted immediately at entry and be managed as state, so you wouldn't be working with a…

> The future of programming should be one language for all layers of the stack, Programmers will never agree on what this language should be.Ever. Because different tasks require different features,a language that tries to have all these features will be regarded as a mess,and disliked because of it.

Because you're talking about looking at it as data, you can get different views. It's all about viewing and working with the appropriate layer. We do it with civil engineering, we do it with drawing, we even do it with accounting systems. It's not about being all things to all people at all times, but about being the layer of the appropriate things for the appropriate people at the appropriate time.

When we look at code as data, we can look at code in context.

Re: Future of Programming Languages

#50

Post by trias »

bane wrote: post #20

I think whatever the language of the future will be, it's likely that we're going to have to give up editing a bunch of text files. Much of modern programming these days is really about workflow of large teams. It'd be nice to have richer editing areas that allow for things like embedded diagrams and videos as comments, annotations, hypertext links out to documentation and from documentation into code, review comment…

Someday, people will say "I program in HTML" and be correct.
Post reply on HN