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

Loren Segal: Too Lazy to "Type"

gnuu.org

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Loren Segal: Too Lazy to "Type"

#21

Post by ambition »

johnnygood wrote: post #15

This is something that has bothered me about my Ruby usage. A lot of the time, I feel like I'm writing "dynamic" code that really just needs to be pre-processed. class Cool [:ice, :soda, :snow].each do |item| define_method item do #some code end end end There isn't a real reason why that couldn't be pre-processed. I don't know a ton of Java, but the idea of compile-time code generation is appealing. Does anyone know…

Solving this problem in general is a major area of research. Look up "Partial Evaluation."

Re: Loren Segal: Too Lazy to "Type"

#22

Post by grav1tas »

ambition wrote: post #21
johnnygood wrote: post #15

This is something that has bothered me about my Ruby usage. A lot of the time, I feel like I'm writing "dynamic" code that really just needs to be pre-processed. class Cool [:ice, :soda, :snow].each do |item| define_method item do #some code end end end There isn't a real reason why that couldn't be pre-processed. I don't know a ton of Java, but the idea of compile-time code generation is appealing. Does anyone know…

Solving this problem in general is a major area of research. Look up "Partial Evaluation."

Yes! I second this. Partial evaluation is especially compelling stuff for improving efficiency. I'm glad other people on HN are into it.

Re: Loren Segal: Too Lazy to "Type"

#23

Post by aaronblohowiak »

johnnygood wrote: post #15

This is something that has bothered me about my Ruby usage. A lot of the time, I feel like I'm writing "dynamic" code that really just needs to be pre-processed. class Cool [:ice, :soda, :snow].each do |item| define_method item do #some code end end end There isn't a real reason why that couldn't be pre-processed. I don't know a ton of Java, but the idea of compile-time code generation is appealing. Does anyone know…

That code is only run once per application lifetime. Without risking DRY, I don't know what you mean by 'pre-processed'. Do you care if it is run at the parse time instead of the Class Object definition time?

Re: Loren Segal: Too Lazy to "Type"

#24

Post by Xuzz »

chromatic wrote: post #20
Xuzz wrote: post #13

If these dynamic languages are usually used in a mostly-static manner, just without the typing and some added load-time flexibility, doesn't that just mean they operate at a higher level of abstraction? Isn't that a good thing?

Your definition of good may or may not include "do these higher level abstractions preclude, in theory and practice, well-known and cheap optimizations?"

Depends if you care about "code fast" or "develop fast".

Re: Loren Segal: Too Lazy to "Type"

#25

Post by Raphael_Amiard »

JoachimSchipper wrote: post #17
btilly wrote: post #2

The point of the article is that virtually all real Ruby programs could be transformed, after the fact, into statically typed programs. The significant point missed is that I can start typing the program without having figured out what the types will be. After the fact you can do the translation, but postponing having to work out not immediately relevant details is huge for developers.

Type inference (Haskell, C#) can be handy. Optional typing (many Schemes/Lisps, e.g. Gambit-C, SBCL or Clojure) is also an option. I see your point, but dynamic typing is not the only way to get (most of) these benefits, and both of the above show significant performance boosts.

It's really not that hyped up lately, but i really think that optional typing would be the best of both worlds in that matter. You can write your programs without thinking about types, and then you add types for safety/speed.

With a little bit of type propagation i think it would lead to quite a natural style of programming.

C#/CLR hints towards that from the other side with the dynamic type, but for syntaxic and cultural reasons, it won't be the same thing as a dynamic language allowing you to use types.

Also, Clojure type hinting is not at all optional typing, as it doesn't enforce types at all. It's purely for performance reasons, and i really think is the wrong way to go about things.

Re: Loren Segal: Too Lazy to "Type"

#27

Post by jamii »

btilly wrote: post #2

The point of the article is that virtually all real Ruby programs could be transformed, after the fact, into statically typed programs. The significant point missed is that I can start typing the program without having figured out what the types will be. After the fact you can do the translation, but postponing having to work out not immediately relevant details is huge for developers.

Except for short scripts I generally start programming by figuring out what the data will look like. In a strongly typed language I have a built in language for describing my data. Of course the data structures change as the program evolves but I find it massively helpful to have that description up front.

What's that quote? Something like:

"Show me your algorithm and I will remain puzzled, but show me your data structure and I will be enlightened."

Re: Loren Segal: Too Lazy to "Type"

#28

Post by kristianp »

Xuzz wrote: post #24
chromatic wrote: post #20

Earlier quoted context omitted.

Your definition of good may or may not include "do these higher level abstractions preclude, in theory and practice, well-known and cheap optimizations?"

Depends if you care about "code fast" or "develop fast".

It would be cool if a language could be both, by using this research to create a language that recognises the difference between load time and run time. The dynamic parts would be used to load the program, after which dynamic changes would be turned off, allowing function dispatch or whatever it is that is slow in a dynamic language to be sped up.

Re: Loren Segal: Too Lazy to "Type"

#29

Post by thesz »

btilly wrote: post #2

The point of the article is that virtually all real Ruby programs could be transformed, after the fact, into statically typed programs. The significant point missed is that I can start typing the program without having figured out what the types will be. After the fact you can do the translation, but postponing having to work out not immediately relevant details is huge for developers.

The most exciting thing about types is that they can completely prevent you from typing that program.

If you cannot figure proper types, you won't write proper program. You "fail early".

Re: Loren Segal: Too Lazy to "Type"

#30

Post by thesz »

Raphael_Amiard wrote: post #25
JoachimSchipper wrote: post #17

Earlier quoted context omitted.

Type inference (Haskell, C#) can be handy. Optional typing (many Schemes/Lisps, e.g. Gambit-C, SBCL or Clojure) is also an option. I see your point, but dynamic typing is not the only way to get (most of) these benefits, and both of the above show significant performance boosts.

It's really not that hyped up lately, but i really think that optional typing would be the best of both worlds in that matter. You can write your programs without thinking about types, and then you add types for safety/speed. With a little bit of type propagation i think it would lead to quite a natural style of programming. C#/CLR hints towards that from the other side with the dynamic type, but for syntaxic and cul…

I once read lispers discussion on Qi language. One (actual) Qi user told us that he managed to prove that number 42 has type String.

This is the price of optional typings. It leave random holes in your program.

Post reply on HN