Near Future of Programming Languages [pdf] • Hacker News Board

Re: Near Future of Programming Languages [pdf]

#61

Post by aryehof » Mon, Oct 30, 2017, 5:55 AM UTC

My 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 analysis, information (data) modeling, and object-based decomposition.

Many newcomers I meet only know modeling problem domain concepts as data in a database, with behavior and constraints acting on that data in a separate layer, organized using functional decomposition. Of course that layer increasingly approaches a 'big ball of mud' as size and complexity increases. Sounds a lot like we are back data-flow modeling as so popular in the 1980's, in a new guise.

A focus on programming languages in my opinion, masks the real issues we face.

Re: Near Future of Programming Languages [pdf]

#62

Post by angled » Mon, Oct 30, 2017, 5:59 AM UTC

polymeris wrote: post #58

yogthos wrote: post #37

Earlier quoted context omitted.

I recommend taking a look at Clojure Spec https://clojure.org/about/spec or Racket Contracts https://docs.racket-lang.org/guide/contracts.html

I get clojure.spec is primary a way to define a schema and validate against it, and that you can use it for automatic test generation, too. But I feel I fail to grok the whole extent of the possibilities it offers. Does it address any of the other things YZF mentions? Specially, the "prevent excessive mocking" part?

Eiffel? https://www.eiffel.com/values/design-by-contract/introductio...

Re: Near Future of Programming Languages [pdf]

#63

Post by ShallowLearning » Mon, Oct 30, 2017, 6:13 AM UTC

aryehof wrote: post #61

My 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…

Much of the time, new languages lead to new design paradigms. As a general rule, newer languages are more abstracted than older ones. When people don't need to get hung up on the intricacies of low level programming, real progress can be made on the design paradigm front.

Re: Near Future of Programming Languages [pdf]

#64

Post by WalterBright » Mon, Oct 30, 2017, 6:17 AM UTC

YZF wrote: post #16

One 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…

It many not be exactly what you want, but D supports unit tests embedded directly in the production code:

  https://dlang.org/spec/unittest.html

It's been a real game changer for us in improving the quality of the code.

Re: Near Future of Programming Languages [pdf]

#65

Post by 35bge57dtjku » Mon, Oct 30, 2017, 6:23 AM UTC

tomelders wrote: post #26

YZF wrote: post #16

One 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…

I don’t do coding tests. I talk to the candidate about programming and I only require one interview. I haven’t made a hiring mistake in 6 years.

I'd love to know how you do that, but the answer is always, "I just ask them the right questions and can tell by their answers," which is so vague it's useless.

Re: Near Future of Programming Languages [pdf]

#66

Post by tiuPapa » Mon, Oct 30, 2017, 6:29 AM UTC

YZF wrote: post #16

One 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…

Doesn't Rust and cargo do this kinda well?

Re: Near Future of Programming Languages [pdf]

#67

Post by 35bge57dtjku » Mon, Oct 30, 2017, 6:31 AM UTC

fulafel wrote: post #51

stmw wrote: post #45

Earlier quoted context omitted.

I don't really see where you get that. Is dynamic typing demonstrating a lot of sustainable success?

I edited in the Clojure part after you replied. Languages that have forgone static typing aren't necessarily trying to solve everything using language types at runtime. See eg Clojure's approach. Or SQL's. But at the base popularity-contest level the answer is clearly yes: Dynamic languages have been on a roll for the last 30 years - Perl, Python, Ruby, Erlang, Clojure, even JS.

That certainly doesn't mean it's because of their dynamic typing. And Erlang and Clojure, as nice as they are, are still about as popular as AWK is.

Re: Near Future of Programming Languages [pdf]

#68

Post by zbraniecki » Mon, Oct 30, 2017, 6:32 AM UTC

tiuPapa wrote: post #66

YZF wrote: post #16

One 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…

Doesn't Rust and cargo do this kinda well?

I really like how rust does unit test in line and in docs.

Re: Near Future of Programming Languages [pdf]

#69

Post by TeMPOraL » Mon, Oct 30, 2017, 6:45 AM UTC

rexpop wrote: post #60

YZF wrote: post #16

One 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…

Forgive me, this is going to sound snarky but I promise I am earnest: > I'd also like to specify various injection points for tests right as I'm writing the code You mean, like methods/functions? > extract some arbitrary subset of the code and surround it with tests You mean, like modules/classes?

Kind of, but three big problems in practice are:

- runtime state you need to initialize if your code is written in a stateful manner

- other methods/functions in different modules/classes the code you want to test calls out to

- the fact that method/function and module/class separation is (and IMO always should be) primarily driven by needs of production architecture, not testing, means that it may not be perfect for testing needs

Add to that the failure of testing tools and methodologies (like "don't test private methods" meeting "separate out duplicated or complex code into private methods"), and I feel the problems are real.

----

Here's an idea that just popped into my head right now: how about "hash-based testing"? You take a code you want to test, like:

  private Integer foo(String bar, Frobnicator quux) {
    String frob = quux.invokeMagic(bar);
    return memberApi.transform(frob);
  }

and turn it into:

  Method cut =  3);
  }>>;
  
  //continue testing cut()

The idea being, the compiler or whatever external tooling ensures that the original method in production code, and the inline-modified method in tests, are the same with respect to some equality/hashing function that always treats expressions "foo" and "MOCK(foo) AS(bar)" as equal.

This way, you end up being able to mock everything precisely, inline, in whatever way you see fit, with your tooling ensuring that the actual code stays in sync with the test, since whenever the original method changes in any meaningful way, you'll fail the code "equality" test.

Might be a stupid idea, I welcome comments.

(INB4 testing to implementation instead of the interface - if you have to mock anything, you're already testing to implementation, and this way you can inject testing alterations precisely, instead of having to turn your architecture inside-out to support IoC/DI/whatever the current testing-enabling OOP fad is.)

Re: Near Future of Programming Languages [pdf]

#70

Post by rurban » Mon, Oct 30, 2017, 6:48 AM UTC

drefanzor wrote: post #7

TLDR The future of programming languages should involve not naming your language "Coq". I know I am going through the lowest common denominator, but how do you explain to your boss that you're proficient with using Coq. Ugh. Or professor, since apparently it's a proofing language for academia.

Same problem as with nimrod. Now as Nim it works better.