Live data from Hacker News

Programming paradigms that change how you think about coding

brikis98.blogspot.com

191–200 of 206 posts

Re: Programming paradigms that change how you think about coding

#191
post #25
post #2

In the "concurrent by default" section I would add the hardware description languages like VHDL and Verilog. Learning Verilog was an eye opening experience for me. It reminded me of the time I switched from unstructured BASIC to C when I was a kid. At first it seems complex and weird then suddenly it clicks and it all starts making sense.

... and then suddenly you realize what a horrible, horrible language it is. I'm not exaggerating, it isn't even well-suited for the domain it is mainly used for (i.e., designing digital hardware circuits). For example: 1) Synthesis/simulation mismatch: Your design might work in simulation but not in hardware, and vice versa . Often, this is due to X-value (representing unknown/invalid values) problems. 2) Signed data…

The problems you mentioned are all easily bypassed by design guidelines.

1) (At least at the X's point) Don't build designs that rely on X behavior or could result in X behavior. Where I work, X's are completely unacceptable and a sign that something is broken. In general, if writing Verilog to model hardware, don't write non-synthesizeable constructs.

2) Signed datatypes don't make any sense when designing hardware. Verilog treats everything as bit vectors. While 2's complement can implement signed behavior, hardware doesn't know or care about signed types. Again, if modeling hardware, write code that models hardware.

3) This is annoying, but another issue that is stepped around with design practices and not a major problem.

Overall, when talking about Verilog, you have to keep in mind its a language built to model hardware. Most features of modern languages don't make much sense in that context.

Re: Programming paradigms that change how you think about coding

#192
post #25

Earlier quoted context omitted.

... and then suddenly you realize what a horrible, horrible language it is. I'm not exaggerating, it isn't even well-suited for the domain it is mainly used for (i.e., designing digital hardware circuits). For example: 1) Synthesis/simulation mismatch: Your design might work in simulation but not in hardware, and vice versa . Often, this is due to X-value (representing unknown/invalid values) problems. 2) Signed data…

I wholeheartedly agree. I'm a CSE Major and I took a hardware design class last fall, we programmed and Xilinx FPGA using VHDL. It was a huge change from everything I had learned before, I had no idea what a latch was and why it was bad to imply them. The thing that bothered me the most was the simulation/synthesis disconnect, the only efficient way to debug a program is by using the simulator because debugging it on…

Not knowing what a latch is or why it is bad seems like more a failure of the class than an inherent problem with Verilog. There are times when a latch is useful and desired (though most often not and most often a normal flop structure is better).

With hardware design, you have to keep in mind that you are modeling hardware. A language that did it all for you might be nice, but you still have to know what framework you are working in. The simulation/synthesis disconnect is inherent to that. You can think of a ton of structures that seem fine at a code level but just don't have a workable analog in silicon. Synthesis in that sense is just another debug tool.

Re: Programming paradigms that change how you think about coding

#193
post #109
post #83

Earlier quoted context omitted.

> if it's possible for that type to be out of the range of your constraint....If that's so, it throws an error. If I'm understanding you correctly, that would seem to take a lot of the power out of dependent type systems. Almost all values will eventually depend on input from the outside world, so it seems you'd rarely have a chance to use your dependent type system. Haskell (which doesn't have dependent types baked…

> But how do you get from untrusted, potentially invalid data into the world of trusted, guaranteed-valid data? The main point is that you can write provably correct validation functions. Then your program can branch on the result of that function, and in the "success" branch you can process data further, as usual, assuming (justifiably) the validity of the data. It doesn't make any difference whether some particular…

As a sort of side note, why is it

    filter p (x :: xs) with (filter p xs)
        | (_ ** xs') = if p x then (_ ** x :: xs') else (_ ** xs')
rather than

    filter p (x :: xs) = if p x then (_ ** x :: snd (filter p xs)) else (_ ** snd (filter p xs))

?

Re: Programming paradigms that change how you think about coding

#194
Would be good to add Mozart/Oz.

Dealing with process coordination using the resolution of logical variables gave me a refreshing new perspective. The finite domain constraint system design in Oz is an awesome example of this in action.

An interesting tidbit - the Mozart/Oz team invented "pickling" before it caught on with Python.

Re: Programming paradigms that change how you think about coding

#195

Earlier quoted context omitted.

I've used graphical programming in the past. It sounds amazing in abstract, but ends up being a mess when it is implemented. It basically requires a "sufficiently smart editor", which, even if implemented perfectly, would not leave a lot of room for a third-party ecosystem to be built around the language. There are many solved problems in text-based programming that would need to be resolved in order for a graphical…

The solution that comes to mind is that the graphical elements are backed by text for these purposes. Then, the graphical interface amounts to an editor for this meta-language.

Inevitably, that is what is attempted. But it doesn't solve the use cases I mentioned.

To take a diff for example, not only do you need to illustrate the diff version of (I drew a new line from here to here and made this other box green), you would also need to illustrate patches to textual details and how they related to the graphical code.

Maybe I can imagine a solution that could do that (at great expense). I cannot imagine the language being friendly enough that third-party compilers, IDEs, or static-analysis tools would be feasible.

Re: Programming paradigms that change how you think about coding

#196

Earlier quoted context omitted.

So that was "You can always just refuse to run any function [at] compile time that has not yet passed termination check."? All of this is certainly the case, and useful, and interesting. It doesn't contradict the point that 1) guaranteeing termination and 2) guaranteeing you return "no" on every incorrectly typed program are incompatible, which was approximately the original question.

I can write a compiler in 5 minutes that handles both #1 and #2. It returns no on every program. Therefore it always terminates and always returns "no" on every incorrectly typed program.

Someone beat you to it.

https://news.ycombinator.com/item?id=7569967

Re: Programming paradigms that change how you think about coding

#197
post #102
post #83

Earlier quoted context omitted.

> if it's possible for that type to be out of the range of your constraint....If that's so, it throws an error. If I'm understanding you correctly, that would seem to take a lot of the power out of dependent type systems. Almost all values will eventually depend on input from the outside world, so it seems you'd rarely have a chance to use your dependent type system. Haskell (which doesn't have dependent types baked…

I think a better example is the partial functions in Haskell like head or tail. They throw an exception on empty lists. You could make it return maybe [a] or a default value, but a common usage of head might be where you know yourself that the list is non-empty. Like: head . sort . f where f is a function that you know returns a non-empty list, perhaps because that's just the way it operates or because you checked it…

"You wouldn't even need to run the program if you could prove absolutely anything about the properties of a program."

That's not really true.

Re: Programming paradigms that change how you think about coding

#198
post #88
post #76

Earlier quoted context omitted.

Gödel guarantees that full-blown theorem provers, even with human guidance, cannot prove all true statements about sufficiently rich systems. 'Sufficiently rich' here just means 'includes Peano arithmetic', and you can find tons of tutorials for doing just that (Church encoding) in even the simplest type systems. (This bit of pure-mathematics wonkery ignores the substance of jarrett's question, though; one doesn't ne…

> can never account for data that are provided only after compilation It seems to me they could. Suppose my program depends on external input D. That input could be a file it loads, keyboard input, network input, or anything else. Could I declare that I expect D to have properties P? And then, could the language force me to implement a code path for cases where D does not satisfy P? An example of such a code path wou…

Yes, this is a good point. I hope that what I meant was reasonably clear, but a more precise would have been something like "cannot prove certain assertions about data that are provided only after compilation".

Re: Programming paradigms that change how you think about coding

#199

Earlier quoted context omitted.

I wholeheartedly agree. I'm a CSE Major and I took a hardware design class last fall, we programmed and Xilinx FPGA using VHDL. It was a huge change from everything I had learned before, I had no idea what a latch was and why it was bad to imply them. The thing that bothered me the most was the simulation/synthesis disconnect, the only efficient way to debug a program is by using the simulator because debugging it on…

Not knowing what a latch is or why it is bad seems like more a failure of the class than an inherent problem with Verilog. There are times when a latch is useful and desired (though most often not and most often a normal flop structure is better). With hardware design, you have to keep in mind that you are modeling hardware. A language that did it all for you might be nice, but you still have to know what framework y…

> Not knowing what a latch is or why it is bad seems like more a failure of the class than an inherent problem with Verilog.

You misunderstood the problem: It's not a problem that you can describe a latch, but that it's so easy to make the mistake of describing a latch instead of combinational logic. It's a common mistake and clearly a failure of the language, because two very different intents are described by very similar code.

> The simulation/synthesis disconnect is inherent to that. [...]

No, you're confusing simulation/synthesis mismatch with non-synthesizable code. The former means that simulation gives you different results than the hardware at runtime, which is a very bad thing and should be avoided wherever possible (that's the point of simulation, after all). The latter is unavoidable to a certain degree if the HDL should be usable for simulation.

Re: Programming paradigms that change how you think about coding

#200
post #25

Earlier quoted context omitted.

... and then suddenly you realize what a horrible, horrible language it is. I'm not exaggerating, it isn't even well-suited for the domain it is mainly used for (i.e., designing digital hardware circuits). For example: 1) Synthesis/simulation mismatch: Your design might work in simulation but not in hardware, and vice versa . Often, this is due to X-value (representing unknown/invalid values) problems. 2) Signed data…

The problems you mentioned are all easily bypassed by design guidelines. 1) (At least at the X's point) Don't build designs that rely on X behavior or could result in X behavior. Where I work, X's are completely unacceptable and a sign that something is broken. In general, if writing Verilog to model hardware, don't write non-synthesizeable constructs. 2) Signed datatypes don't make any sense when designing hardware.…

1) > Don't build designs that rely on X behavior or could result in X behavior.

Although I agree, you can't completely avoid 'X' values, because third-party cores might return them in output signals.

2) > Signed datatypes don't make any sense when designing hardware.

Now that is just plain and utterly wrong. Of course signed datatypes make sense when designing hardware: You can (and have to) perform arithmetic in hardware, and signed arithmetic is a part of arithmetic.

> Verilog treats everything as bit vectors.

By your argumentation, unsigned datatypes also wouldn't make sense when designing hardware. And yet you need it all the time.

> hardware doesn't know or care about signed types

But the language should care about it. "It's all 0s and 1s in the end" is not an argument for not providing proper abstractions.

3) > This is annoying, but another issue that is stepped around with design practices and not a major problem.

That's like saying "you can avoid bugs if you're really careful". Great. A "feature" which doesn't offer any advantage (because you're supposed to avoid it anyway) and which makes it so easy to make mistakes which won't be seen until simulation, should have never made it into the language.

> Overall, when talking about Verilog, you have to keep in mind its a language built to model hardware.

Exactly. Verilog and VHDL were intended to model hardware, not to design it. Nowadays, they are mostly used to design it.

I don't mean to attack you, but attitudes like yours are the main reason why we're stuck with such crappy, ill-designed, inappropriate languages for hardware design. You're so used to the problems that you don't even see them anymore.

Post reply on HN