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

31–36 of 36 posts

Re: Loren Segal: Too Lazy to "Type"

#31

Post by Xuzz »

kristianp wrote: post #28
Xuzz wrote: post #24

Earlier quoted context omitted.

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.

Basically, a (very!) enhanced preprocessor? That would definitely be useful.

Re: Loren Segal: Too Lazy to "Type"

#32

Post by sha90 »

aaronblohowiak wrote: post #23
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?

Pre-processed here likely means what you think it means. DRY is not really a concept meant to be applied to method definitions (IMO), but rather method bodies-- of course there are many ways to abuse the interpretation of DRY as well. As far as whether you should care about compile vs load time-- in Ruby you don't need to, but if the language had static typing, it would make a difference.

Re: Loren Segal: Too Lazy to "Type"

#33

Post by supersillyus »

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?

For some definitions, yes, they are operating at a higher level of abstraction. However, abstraction isn't by itself a good thing.

Re: Loren Segal: Too Lazy to "Type"

#34

Post by jeff95350 »

jamii wrote: post #27
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 stru…

Exactly.

To often, I think we're focused on the writing of code rather than the reading of code. Annotations sometimes seem repetitive, but repetitive can aid the readability.

Type inference might be a very nice compromise. Haskell allows you to annotate with type information, and that may provide more helpful errors, but usually it's optional. But people do it anyway, because type information tells a reader so much about the program.

If we just focus on writing, then clearly the programming language is meant only for unidirectional communication from a human to a computer. But if we focus on reading as well, then it becomes about humans communicating with other humans.

Re: Loren Segal: Too Lazy to "Type"

#35

Post by stephen »

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…

I think the reason is merely that compile-time metaprogramming hasn't been adopted in any mainstream programming language (yet).

Boo can do cool things like that though:

http://bamboo.github.com/2010/07/11/boo-meta-programming-fac...

Re: Loren Segal: Too Lazy to "Type"

#36

Post by jamii »

thesz wrote: post #30
Raphael_Amiard wrote: post #25

Earlier quoted context omitted.

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.

This paper presents an optional type system where type errors can only occur in the untyped sections:

http://homepages.inf.ed.ac.uk/wadler/papers/blame/blame-sche...

Post reply on HN