[go-nuts] Wrote a language in Go --- how to do FFI, ineteroperability etc?
I was just showing my lang to people and someone said "What do Charm's FFI capabilities look like? It sounds like it would be pretty well suited for writing wrappers that provide APIs for existing software, so an excellent FFI would be nice." Well, that's still a little way down my todo list but I can see it coming, and so far I have nothing to go on except a sanguine assumption that Go can do for me what C does for Python. But how would I go about it? How about interoperability, putting bits of Go in a Charm script or bits of Charm in a Go program? At present, I wouldn't even be able to explain to you how to make it so you can import a Charm library that wraps around Go functions if the Go functions weren't in the interpreter at compile time. All this stuff is unfamiliar to me, and I'm beyond the point where there will be a cheerful book called "Let's Write An FFI In Go!" with cartoons in it. Failing that, what should I be looking at? Thanks for your advice. Tim. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d1233aa0-c458-4c55-ba03-5e890ac722bdn%40googlegroups.com.
Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.
True, I don't say that meaningful names can entirely replace comments, just that comments can't replace the sort of meaningful if verbose names that OP objects to in point (1). A lot must depend on the personal equation, how well one reads chunks of camelCase, how well one reads abbreviations, how good one's memory is, how fast one types, etc. Personally I find I just mess up less since I've learned to be more verbose. On Saturday, January 29, 2022 at 9:00:49 AM UTC-8 david@gmail.com wrote: > On Sat, Jan 29, 2022 at 6:21 AM Tim Hardcastle > wrote: > >> Agree with Rudolf on point 2. Long meaningful variable/function names are >> good. Comments become obsolete, they become detached from their code, >> they're only used to explain the name of the variable once and then you're >> left with something than reads >> >> // urn contains the userlist >> fxn := rx (frn) >> >> Now that editors have autocomplete to make up for my meagre typing >> speed, you bet your ass I'm going to have [eg from current project] a local >> variable called lastTokenWasColon and a method called addWordsToParser. >> Because knowing exactly what they do when I need to modify or debug saves >> me so much time and trouble. (Perhaps this varies from person to person. If >> my memory is poorer than yours, it has more of an upside for me than for >> you.) >> > > There's a lot of middle-ground between a three-letter variable or > function-name and encoding the whole doc-comment for a function or variable > in its name. > Humans only have so much working memory, once a name gets long enough we > start dropping parts of the name and it tends to be stuff in the middle > that gets dropped. > > If you have a parser type, and a variable with that type, often, it would > be better to have an addWords() method on the parser type. Then if you also > need a special-case addWord() it's easy to tell what's going on. > > I try to have meaningful names, but beyond some threshold, but I try to > prevent things from being redundant with the types involved (the entire > function signature and type of the variable). > > Also, comments are not about just describing what something is. (those are > the least useful types of comments) They're also quite useful for > describing what's being attempted, what corner-cases are being addressed > and if there's any tricky logic that needs to be handled. Additionally, > IMO, just about any function or method should have a doc-comment explaining > what it expects. (helpers under ~3 lines may be exempt) > >> >> And is there a better solution to the problem in point 1 than to break >> the function down into lots of little functions *with meaningful names*? >> (If the names (and pieces) aren't meaningful you've only technically broken >> it down.) >> >> On Friday, January 28, 2022 at 10:12:48 AM UTC-8 Rudolf Martincsek wrote: >> >>> > 2) Long variable names. >>> >>> Where I work (not in Go), writing comments is frowned upon. That >>> includes "docblock" style comments. If a function needs to be documented, >>> it means the implementation is too complex and must be broken apart to >>> reduce cyclomatic or whatever perceived complexity. Also uncle bob told us >>> that functions should never be longer than 2-3 lines of code, so it should >>> be enough to look at the source code to see what it does. That's the >>> general sentiment in my team. >>> Comments are considered sign of "un"clean code. >>> >>> So we use long variable and function names to make the code self >>> documenting. (Hint: it doesn't) >>> Points 3,4,5 have similar roots, because in dynamic languages it was a >>> trend many years ago. (ie: hungarian notation) >>> >>> On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote: >>> >>>> 1) Long functions that go on forever and contain long lambdas and 8 >>>> levels of indentation. >>>> >>>> 2) Long variable names. >>>> >>>> 3) Variable names which include the type of the variable. >>>> >>>> 4) Packages whose name contain the word '/pkg/' >>>> >>>> 5) Repos which contain the prefix go- >>>> >>>> 6) Code where almost every line prefixed by `_, _ =` >>>> and the underscores won't go away when you wipe your screen >>>> >>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To un
[go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.
Agree with Rudolf on point 2. Long meaningful variable/function names are good. Comments become obsolete, they become detached from their code, they're only used to explain the name of the variable once and then you're left with something than reads // urn contains the userlist fxn := rx (frn) Now that editors have autocomplete to make up for my meagre typing speed, you bet your ass I'm going to have [eg from current project] a local variable called lastTokenWasColon and a method called addWordsToParser. Because knowing exactly what they do when I need to modify or debug saves me so much time and trouble. (Perhaps this varies from person to person. If my memory is poorer than yours, it has more of an upside for me than for you.) And is there a better solution to the problem in point 1 than to break the function down into lots of little functions *with meaningful names*? (If the names (and pieces) aren't meaningful you've only technically broken it down.) On Friday, January 28, 2022 at 10:12:48 AM UTC-8 Rudolf Martincsek wrote: > > 2) Long variable names. > > Where I work (not in Go), writing comments is frowned upon. That includes > "docblock" style comments. If a function needs to be documented, it means > the implementation is too complex and must be broken apart to reduce > cyclomatic or whatever perceived complexity. Also uncle bob told us that > functions should never be longer than 2-3 lines of code, so it should be > enough to look at the source code to see what it does. That's the general > sentiment in my team. > Comments are considered sign of "un"clean code. > > So we use long variable and function names to make the code self > documenting. (Hint: it doesn't) > Points 3,4,5 have similar roots, because in dynamic languages it was a > trend many years ago. (ie: hungarian notation) > > On Thursday, December 9, 2021 at 2:10:18 PM UTC+2 Amnon wrote: > >> 1) Long functions that go on forever and contain long lambdas and 8 >> levels of indentation. >> >> 2) Long variable names. >> >> 3) Variable names which include the type of the variable. >> >> 4) Packages whose name contain the word '/pkg/' >> >> 5) Repos which contain the prefix go- >> >> 6) Code where almost every line prefixed by `_, _ =` >> and the underscores won't go away when you wipe your screen >> >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6a824f2c-d1b6-43f7-8c07-a1e9b8f5376en%40googlegroups.com.
[go-nuts] Re: Anyone else writing an interpreter with Thorsten Ball?
It's very well-explained and the code's easy to read. And you can build on it. I've been able to modify his code to my language spec, use syntactic whitespace instead of braces, utf8 instead of ASCII, my idea of how continuations should work, line numbers in error messages, the ability to define infixes and suffixes, optional typing in functions, my own notion of conditional syntax, and I've just been able to rationalize my code by getting the 1.18 beta version of Go and implementing a generic Set type. It's going good. Recommend. On Wednesday, January 26, 2022 at 3:15:11 PM UTC-8 kziem...@gmail.com wrote: > I found this books last weeks, on community page of different language and > I consider buying them. But I have a lot thing to learn for Go with > learning materials for free (unicode, UTF-8, Go spec, etc.), that I will > probably postpone this book to the future. If you don't mind, I want to ask > you about your experience of writing interpreter with them. > > Best regards, > Kamil > środa, 26 stycznia 2022 o 20:35:37 UTC+1 timphar...@gmail.com napisał(a): > >> How's it going? I'd just like to talk with someone who's doing the same >> thing, it's kind of a lonely hobby. >> >> I'm just about to start on the actual interpreter, I've got my lexer and >> parser working, and I also have a thing called a "relexer" which is kind of >> an elegant kludge that makes syntactic whitespace work, and an "uberparser" >> which breaks the program down into chunks ... my language is very different >> from Monkey, there's going to be hardly a line of Ball's code left when I'm >> finished, but I couldn't do it without him. >> >> (And for those of you who haven't seen his books, I recommend them, >> they're like crack if crack made you a better and smarter person.) >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/680cea29-9dd7-4f1d-af04-b253fee2c663n%40googlegroups.com.
[go-nuts] Anyone else writing an interpreter with Thorsten Ball?
How's it going? I'd just like to talk with someone who's doing the same thing, it's kind of a lonely hobby. I'm just about to start on the actual interpreter, I've got my lexer and parser working, and I also have a thing called a "relexer" which is kind of an elegant kludge that makes syntactic whitespace work, and an "uberparser" which breaks the program down into chunks ... my language is very different from Monkey, there's going to be hardly a line of Ball's code left when I'm finished, but I couldn't do it without him. (And for those of you who haven't seen his books, I recommend them, they're like crack if crack made you a better and smarter person.) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/347e5645-d307-4bde-8f5c-90d78101ee14n%40googlegroups.com.
