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

Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

tcl.tk

Post reply on HN
Print view View original

21–30 of 42 posts

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#21

Post by keypusher »

jjr wrote: post #17
sreque wrote: post #16

Earlier quoted context omitted.

It's worse than that, unfortunately. Everything is implicitly convertible to a string, and every string is implicitly convertible to any other type. So, if you pass a dictionary into your function that expects a list, it will happily convert between types for you. I do not like this sort of behavior in my dynamic type system.

But a dict is a list of paired elements? I do like the fact that you can convert freely between string/list/dict. It removes a lot of boilerplate type conversion. Want to serialize a dict? In most languages that's boring code. In Tcl it's so easy you do it all the time.

Depends on the language, but I prefer the Python approach here. Python is a dynamically (but strongly) typed language. If you want a list from a dict, get a new list via casting ie. list(the_dict), or get a list from either side via the_dict.keys() or the_dict.values(). Weakly typed languages that will do implicit type conversion for you such as TCL and Perl seems prone to mistakes and confusion from this stuff as code complexity of the project grows. I don't think Python gets it right here either though really, as in the end explicit types save so much headache and stupid bugs by finding problems for you at lint or compile time.

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#22

Post by yfyf »

michaelhoffman wrote: post #11
to3m wrote: post #7

The explicit tail calls look pretty neat. All languages should include this, or something like it, I think; tail calls come in handy for all sorts of things. Making it explicit sidesteps complaints about how it will impede debugging, and ensures programmers will definitely get it where they want/expect. I think this would be a chance to rehabilitate the much-maligned GOTO keyword. But "tailcall" is probably just as g…

Python language creator Guido von Rossum prevents CPython from having tail call optimization because he doesn't want people to use it. http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...

I wonder if he would claim the same argument today as he does in this[1] comment, in particular the paragraph "On side effects being bad ".

I would dare to claim that there's some trend to do things more side-effectlessly not only in programming, but also in general, people in IT are finally realizing* that the more isolated, light-weight and modular things are (think of increased interest in functional programming (pure functions), dominance of cloud-based/inspired solutions (spinning up small instances of VMs)) the better. Somehow this particular mindset helps at all levels.

Hah, there's actually a term for what I'm trying to describe: Shared nothing architecture[2]. Allowing side-effects on any level implies "sharing" to me.

[*]: of course you could say "this has always been the case", but somehow some years ago Java and the friends seemed like the only "enterprise level" solution to most businesses and the general fat-stack+vertical-scaling seemed somewhat reasonable.

[1]: http://neopythonic.blogspot.nl/2009/04/tail-recursion-elimin... [2]: http://en.wikipedia.org/wiki/Shared_nothing_architecture

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#23

Post by gnachman »

mitchi wrote: post #3

Is this the programming language that works without a lexer/parser and a grammar? Why aren't there more programming languages written this way? Seems easier to implement.

The parser's behavior is not specified except in the implementation, which is messy C. I was once loosely involved in a project that tried to reimplement it, which turns out to be extremely difficult, and was laughed at by Brent Welch. Indeed, it failed on countless edge cases. lex and yacc (or whatever) at least isolate this part of the language, making it much easier to have more than one implementation.

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#24

Post by mahmud »

yfyf wrote: post #22
michaelhoffman wrote: post #11

Earlier quoted context omitted.

Python language creator Guido von Rossum prevents CPython from having tail call optimization because he doesn't want people to use it. http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...

I wonder if he would claim the same argument today as he does in this[1] comment, in particular the paragraph "On side effects being bad ". I would dare to claim that there's some trend to do things more side-effectlessly not only in programming, but also in general, people in IT are finally realizing* that the more isolated, light-weight and modular things are (think of increased interest in functional programming (…

I don't think the world of software development changed at all since 2009. It takes about 15 years to see noticable shifts in practices.

Also, shared-nothing "architecture" goes back to the 60s with the first investigations into concurrency. In fact, if I were being pedantic, I would say it predates computing itself: logic is all side-effect free.

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#25

Post by skoob »

jjr wrote: post #17
sreque wrote: post #16

Earlier quoted context omitted.

It's worse than that, unfortunately. Everything is implicitly convertible to a string, and every string is implicitly convertible to any other type. So, if you pass a dictionary into your function that expects a list, it will happily convert between types for you. I do not like this sort of behavior in my dynamic type system.

But a dict is a list of paired elements? I do like the fact that you can convert freely between string/list/dict. It removes a lot of boilerplate type conversion. Want to serialize a dict? In most languages that's boring code. In Tcl it's so easy you do it all the time.

> But a dict is a list of paired elements?

Not really. A dict is an unordered set of keys where each key has a value associated with it. If you try to access a dict as a list, you might expect to get a list of key-value pairs or a list of values or possibly a list of keys. And in what order will the elements in the list be?

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#26

Post by lolcraft »

michaelhoffman wrote: post #11
to3m wrote: post #7

The explicit tail calls look pretty neat. All languages should include this, or something like it, I think; tail calls come in handy for all sorts of things. Making it explicit sidesteps complaints about how it will impede debugging, and ensures programmers will definitely get it where they want/expect. I think this would be a chance to rehabilitate the much-maligned GOTO keyword. But "tailcall" is probably just as g…

Python language creator Guido von Rossum prevents CPython from having tail call optimization because he doesn't want people to use it. http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...

Well, to be trollish :), he also didn't want it because:

1 - With TCO, there would be no more "recursiveFunction recursiveFunction recursiveFunction" x 1000 stack traces. Which apparently is bad. Might force someone to use a debugger, you know.

2 - Non-standard Python implementers won't be competent enough to code it, so it's best he doesn't force them to.

3 - He doesn't believe in recursion. He doesn't like it. I mean, the look of it. It's too nerdy.

4 - He made a bad choice in basing his language in dynamic binding. He recognises it, says it's horrible style, un-pythonic, but won't make it go away because users, users, yadda yadda. All this from someone whose job description is BDFL ;)

Yeah, I'm bitter about some minor quirk no one cares about, but... you know, I might have preferred a "I can't be arsed to do it" answer. Those arguments are pretty laughable.

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#27

Post by RHSeeger »

sreque wrote: post #16
jeffh wrote: post #10

Earlier quoted context omitted.

While the EIAS philosophy is true in Tcl, at the real guts level, the actuality is "Everything must be representable as a string". EMBRAAS it! There is an object system underneath which handles native or user defined types.

It's worse than that, unfortunately. Everything is implicitly convertible to a string, and every string is implicitly convertible to any other type. So, if you pass a dictionary into your function that expects a list, it will happily convert between types for you. I do not like this sort of behavior in my dynamic type system.

Tcl's EIAS can be annoying at times, but it also allows for an amazingly easy to use language that provides for some amazingly powerful abilities. For example, the ability to build arbitrary control structures with little effort. Most other languages, dynamic or not, can't come close to it's flexibility and some of the things you can do with it.

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#28

Post by yfyf »

mahmud wrote: post #24
yfyf wrote: post #22

Earlier quoted context omitted.

I wonder if he would claim the same argument today as he does in this[1] comment, in particular the paragraph "On side effects being bad ". I would dare to claim that there's some trend to do things more side-effectlessly not only in programming, but also in general, people in IT are finally realizing* that the more isolated, light-weight and modular things are (think of increased interest in functional programming (…

I don't think the world of software development changed at all since 2009. It takes about 15 years to see noticable shifts in practices. Also, shared-nothing "architecture" goes back to the 60s with the first investigations into concurrency. In fact, if I were being pedantic, I would say it predates computing itself: logic is all side-effect free.

Sure, theoretical investigations on things begin many years earlier than anyone starts actually using them, but somehow "concurrency" wasn't something available to your everyday Joe back in 60s, right? Multi-core wasn't the norm, there was no elastic cloud, what so on.

And I am not really claiming that software development changed much in 3 years, but I think people's mindsets are changing faster than that, especially of those who are actively involved in thinking about these things.

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#29

Post by eiji »

The TIP#257[1] (Tcl Improvement Proposal) explains how rich and thought-out the TclOO component is. Endless possibilities. It's a nice read to learn more about OO-concepts like filters, mixins and meta-classes.

Some might ask how TclOO compares to iTcl's. For one the performance is in another league.[2](Version 0.3)

[1] http://www.tcl.tk/cgi-bin/tct/tip/257

[2] http://wiki.tcl.tk/18152#pagetoc16f40cc9

Re: Tcl/Tk 8.6 released (now stackless, w/coroutines, tailcalls, and more)

#30

Post by [deleted] »

keypusher wrote: post #21
jjr wrote: post #17

Earlier quoted context omitted.

But a dict is a list of paired elements? I do like the fact that you can convert freely between string/list/dict. It removes a lot of boilerplate type conversion. Want to serialize a dict? In most languages that's boring code. In Tcl it's so easy you do it all the time.

Depends on the language, but I prefer the Python approach here. Python is a dynamically (but strongly) typed language. If you want a list from a dict, get a new list via casting ie. list(the_dict), or get a list from either side via the_dict.keys() or the_dict.values(). Weakly typed languages that will do implicit type conversion for you such as TCL and Perl seems prone to mistakes and confusion from this stuff as co…

[deleted]
Post reply on HN