mackwic

16 ms·

91.
by mackwic 12y ago
I think you mean "easy to hire"-technology. One time it was Java, then it was PHP, now it's becoming node.js and angular. Maybe it's a bit soon, but it's far from insane to bet on these technologies nowadays.
92.
by mackwic 12y ago
Can you tell us a bit more about the history of the project ? Are you a game developer ? Why did you put so much work in such a huge project ? (thanks for that ! That's wonderful)
93.
by mackwic 12y ago
It's the whole philosophy of ruby: sometimes, it makes more sense to write the index in full letters rather than in digits.
94.
by mackwic 12y ago
Before websockets, some hackers used gifs as an one-way raw socket. Very impressive stuff. Example project: https://github.com/videlalvaro/gifsockets
95.
by mackwic 12y ago
Your link is fabulous ! Thanks for sharing it, that was not-so-well known.
96.
Ask HN: What do you use for managing projects?
3 points by mackwic 12y ago|3 comments
97.
by mackwic 12y ago
Why highly suspect ? We know and use cooperative concurrency since decades. Agreed on the "not suitable for all" but no one said that.
98.
by mackwic 12y ago
It's like learning a new programming language: the more you know how to speak/code/design, the more you can express and understand others. You should have a look to rails, it's still the state of the art in term of frame
99.
by mackwic 12y ago
Even though the question is good, the article answer is disappointing. First, I really don't like the angle taken, then the question of abstraction (why we do it, how) and choices made by languages designers (and variations in their id
100.
by mackwic 12y ago
But Ruby is an acceptable Lisp[0], and has also a lot of libraries. ;) So, how will Lisp compete ? Maybe if we look at it pragmatically, the solution is not in the performance nor in the time to develop, but in the ease of maintaining the s
101.
by mackwic 12y ago
There is always the last bias: lisp programmers, by their strong academical background, tend to be more educated CS-wise than JS, Ruby, or Python programmers, which enable them to a better understanding of a CS problem. It's almost tau
102.
by mackwic 12y ago
Because of clarity ? A function can have a really broad use, and the particular use case is unclear when you call it. In this hypothetical but likely situation, aliasing the general function to a more-specific name is good neighbor behavior
103.
by mackwic 12y ago
It is very good software, no doubt. Erlang wouldn't be so efficient without OTP. It's just a bad example of a good OSS project because it's not really a community project but more like "some guys from ericson which accep
104.
by mackwic 12y ago
Oh come on, you can't seriously say that Erlang/OTP is good open source . It's mildly-good corporate open-source, that's not making it good open source in any way. But that's off-topic. The thing is, code review
105.
by mackwic 12y ago
Please explain the trade off, I can't see myself debugging an unindented XML file without an appropriate reader. Exactly like a binary file.
106.
by mackwic 12y ago
> Taxes should apply to the production or consumption of utility, not to its random shuffling around. The Random shuffling part made me smile. Though, that's only looking at individual cases. When you look at the global picture, it
107.
by mackwic 12y ago
Same goes for C and C++, pretty much exactly the same. Well, I have some bad news for you... :) It's not because it's JS that we can fire the architect, SOLID principles (yes, they still are quite good practices), and abandon all
108.
by mackwic 12y ago
I wrote another comment explaining why I strongly disagree with you (and the Meteor thing) but after reading it I found it harsh and stuffed with negativity. So yeah, I very much disagree with you, but hope I will be wrong and Meteor will b
109.
by mackwic 12y ago
I was just answering the grand-parent question. Could you link the comparison ? Can't find it with simple searches. About the "Go is boring" thing, I also tend to think of Go as a boring language... but no more than C or Java
110.
by mackwic 12y ago
This is really nice ! Thanks !
111.
by mackwic 12y ago
Never done any DSP. How does it change the paradigms ? > At least. that was the theoretical practice. The actual practice was a mess. :( This another big problem yet to solve...
112.
by mackwic 12y ago
Because Rust is not ready for production ?
113.
by mackwic 12y ago
I personally tend to use yaml files which contains matrices of compatibility between objects, used to generate CMake statements. I know people who use the file header to autodetect the right architecture but I found it too overkill and weir
114.
by mackwic 12y ago
> The "when possible" in your statement is a caveat large enough to drive a semi through You are absolutely right. It's a real effort of architecture, and sometimes one of the marks of a great projects. EDIT (thinking of a
115.
by mackwic 12y ago
goroutines and green threads. Some people use coroutines, cooperative threading, channels etc. for years. In fact, the whole Solaris OS threading model was build around some of these features.
116.
by mackwic 12y ago
I like SailsJS a lot but didn't have the chance to experiment it on a real project. How well does it scale ?
117.
by mackwic 12y ago
I don't agree. Popular but legacy chips can have updated tools where new but conservative chips can have odd software packaging. Moreover, embedded development is conservative by nature and I know a lot of teams which prefers to run pr
118.
by mackwic 12y ago
I have to say that the sequence "errordevelopper" responding to "codehero" is quite funny. :)
119.
by mackwic 12y ago
This looks great ! With the JetBrains expertise in IDE, that surely was a missing piece of software. I am slightly concerned by the DSL thing, because I don't want each embedded projects to have specific dialects like we can see on LIS
120.
by mackwic 12y ago
Playing the devil's advocate, here. When possible, this kind of if_arch/else should be compartmentalized in their own object files or dynamic libraries, and then, linked conditionally to produce an unique binary. You shouldn'

More ›