61–70 of 81 posts
Author here. I was just about to go sleep when I noticed a retweet and a lot of new stars on Conception; this explains it. The linked C++ project was the result of an initial year of working on it, which culminated in a winning entry to LIVE 2013 contest [1] and me switching to working on a version of it written completely in Go [2]. I no longer work actively on the C++ version, but I do on the Go one [3]. Primarily,…
Earlier quoted context omitted.
For me, the language of a project has a large impact on whether I would consider contributing to it or not. When I dislike the language, I'll usually not want to be involved with the project, but just watch it growing. Thus, it makes a project more interesting for me if the language is nice.
I know. That’s kind of true for all of us. But yet I believe this is not that important. Specially not important enough to put the language like a badge of honor beside the project’s name or description in the title, like how these “written in Go”s are. If a projects seems interesting enough for someone, it’s more than easy to see what language is it written in. BTW, that’s how things work: you don’t decide to contri…
Example: You might not be interested in writing a text editor, but you've seen this and the lime project, both written in Go, you don't care for writing a text editor, but you might figure you could spend some time to this guy fix an issue in your free time.
Is the above a little far-fetched? Maybe, is it unrealistic? Not really.
Earlier quoted context omitted.
People can be interested in the link for two different reasons, now. Some people want to see a new editor; some people want to see the source code. I have a search set up that emails me daily about Clojure topics on HN. I'd be very interested to see new editors written in Clojure, and not very interested in using the editors themselves.
Setting up email alerts for Clojure stories sounds useful. Can you describe how you do that? I couldn't find a way to set up alerts, either using hn.algolia.com or using Google Alerts.
Author here. I was just about to go sleep when I noticed a retweet and a lot of new stars on Conception; this explains it. The linked C++ project was the result of an initial year of working on it, which culminated in a winning entry to LIVE 2013 contest [1] and me switching to working on a version of it written completely in Go [2]. I no longer work actively on the C++ version, but I do on the Go one [3]. Primarily,…
Can you give some examples? It might be very valuable to share your conclusions.
Earlier quoted context omitted.
> Who cares how long the file is? Every software developer worth his (or her) salt. > what matters is the formal structure of the code Yes, and splitting code into well named files is a starting point for giving it proper structure. The same goes for the size of your functions. Here some (like "ProcessEvent") consist of nearly 500 lines... that's roughly 10 screens. Textbook spaghetti code. Overly long code files are…
That's not what 'spaghetti code' means.
Earlier quoted context omitted.
...and source control
There was a "commit and push" in the demo video somewhere, so I'm assuming this is source-control-compatible.
Earlier quoted context omitted.
PR seriously. Link had far less chances to get on the fromt page without PR keywords like "written in Go". Still interesting tho.
You’re right. What makes this project interesting is the idea and the design, not Go, yet it would be much harder to get this publicity through that. And that’s exactly what I’m saying: why should people upvote just because of the language?
Earlier quoted context omitted.
This is one of those "software engineering best practices" that sounds nice but has no basis in reality. What matters is the formal structure of your program: types, composition, state, capabilities. Where your code is located on the filesystem is incidental complexity. My thinking is more along the lines of http://erlang.org/pipermail/erlang-questions/2011-May/058768... and http://tonymorris.github.io/blog/posts/ide…
> This is one of those "software engineering best practices" that sounds nice but has no basis in reality Are you a programmer? What languages? > Where your code is located on the filesystem is incidental complexity. Incidental complexity is still complexity to deal with. It isn't easy for me as a developer to find such and such routine if you've thrown everything into a big bucket named "main". You also omitted the…
Perhaps the better storage layer would be function definitions living in a database. That Conception uses an unindexed flat file as the 'code database' also isn't surprising given the stage of development.
Earlier quoted context omitted.
That's not what 'spaghetti code' means.
No? Why? By what definition?
Spaghetti code refers to the complexity of tracing cause/effect through a set of routines increasing to the point where you can no longer safely add functionality or fix bugs without too high a risk of regressions. It has to do with the difficulty of understanding the purpose, intent, actions, and side-effects of each function.
As is often the case, splitting a function too much simply based on a LOC guideline can result in spaghetti code just as easily as it may guard against it. Functions should be atomic, re-usable, repeatable, clearly defined, and well encapsulated.
I don't see lines of code as a direct factor in judging a function implementation, as long as those lines are spent moving the feature forward and not violating "DRY".
Earlier quoted context omitted.
This is one of those "software engineering best practices" that sounds nice but has no basis in reality. What matters is the formal structure of your program: types, composition, state, capabilities. Where your code is located on the filesystem is incidental complexity. My thinking is more along the lines of http://erlang.org/pipermail/erlang-questions/2011-May/058768... and http://tonymorris.github.io/blog/posts/ide…
> This is one of those "software engineering best practices" that sounds nice but has no basis in reality Are you a programmer? What languages? > Where your code is located on the filesystem is incidental complexity. Incidental complexity is still complexity to deal with. It isn't easy for me as a developer to find such and such routine if you've thrown everything into a big bucket named "main". You also omitted the…
>
>A module should not contain more than 400 lines of source
>code. It is better to have several small modules than one
>large one.