I guess you could say we've had similar experiences, I wouldn't be this motivated to find another way if I thought Lisp or Forth was the final answer either. Or Smalltalk, I was really excited about Strongtalk for a while. I've had this gut feeling for a long, long time that it's quite possible to add more structure without taking away the power; and doing it in Forth proves the point.
But the more code I write, the more I appreciate languages that stay out of my way until I ask for help; besides Lisp & Forth that basically means C/C++. Elaborate syntax, no matter how convenient; will always become an obstacle at some point. You might think it's funny to see C++ in that list, but these days its possible to use it as a static Common Lisp with crippled macros; Snabels implementation is a testament to that.
I was deeply in love with the idea of Smalltalk for a long time, but big pieces of code turn spongy on me as soon as I pass a certain level of complexity. I need more types than that, which is why Snabel had parameterized types from day one.
Lisp and Forth, everyone gets that reaction on first contact; the real problem is that most popular languages look the same these days. Popularity has very little to do with earning it. And it's getting worse with more and more crapscript lately.
I'm not very much into dogmatics and orthodoxy, Forth wasn't the final answer to anything. Nothing ever is. Implementing the same thing over and over again doesn't make sense to me; I have plenty of experience of my own that thinks differently, things I always wanted to work differently. So that's what I'm doing, my best to improve the status quo.
May I suggest considering Forth as a substrate? Or will that get me voted straight into neckbeard land?
I've had a lot of fun hacking Forths, writing my own languages didn't really click until I finally had a serious look. Forth skips on most of the complexity of getting from bytes to semantics; even Lisp is complex in comparison; but is still powerful enough to do interesting things; and the best foundation for DSL's I've come across.
Keep telling yourself that; first impressions are vital, you go numb from forcing yourself to conform. I too was 19 years old back in the days, I'm 40 now and I'm more certain than ever that doing my own thing is the only way forward. In-between, I spent a long time playing your game; trying to talk others out of rocking my boat.
This thread was a truly depressing read. Someone is fed up with the bullshit and has the courage to speak their mind, and the best you can manage is throwing stones to protect your own miserable bubbles. Here's some constructive advice: Find something you love to do, then give it your best against any odds and ignore the stones that will inevitably be thrown; you will have to do it sooner or later anyway, or die regretting a wasted life. And forgive them, for they know not who they are.
It looks like, and is often accused of reinventing wheels. Forgetting that it's not about the wheels but what the designers learned from going through the motions. Writing code that you've never written before on a daily basis is a good start. The key is to keep raising the bar, keep questioning tools, frameworks and best practices; to never get stuck on auto-pilot. Solve problems you care deeply about; or if that isn't possible yet; practice on the road-blocks, divide and conquer. At least that's what it's like for me.
If you really mean relational, and not SQL; then all you need is columns, tables and records. Just do it, once you have a stupid implementation of your ideas running you'll know what information to look for. I've been cooking my own relational persistence engines for quite a while now, here is the latest incarnation if anyone is interested in seeing the idea cut down to its core with optional encryption on top:
Except I have 32 years of daily practice and plenty of experience from most paradigms/languages/kinds of software out there. I'm guessing similar goes for some of the hundreds of people who complain about the same thing.
This attitude is exactly why many choose to stay away from Go and its community. The constant denial of any problems and claims that everyone else got it wrong. I don't know where it started, most probably Pike & co; but its not very constructive.
Sure thing. Bear in mind that this is my way of doing it; plenty of people will yell blasphemy at the choices I make, and some may well turn out to be suboptimal without 32 years of experience to back them up.
Likewise, the fact that I've been you makes it even more so.
I believe in experience; and our ability and responsibility to draw conclusions from that experience and speak the truth that we see, especially when it's inconvenient.
I believe in the ability and need to have different, peacefully coexisting views and explanations; to stand up for who we are, and accept others for who they are.
I don't believe in blindly trusting authorities while ignoring experience and shaming others into silence to protect the insanity.
Couldn't agree more, a much better investment of anyones time. C++ won't suddenly refuse to solve your problems because they don't fit into an arbitrarily limited view of the world. And some of the stuff coming out of standardization lately is simply awesome.
I'm sorry, I know the official line is to be dead-scared of anything natural out there but this is just total bullshit.
If sunshine was poisonous to your eyes you would already be blind. I look straight into the sun for several minutes at a time on a regular basis, if it gets uncomfortable I stop; been doing that for most of 40 years, no big deal. The sun is a life source, not our enemy. The only real danger is viewing the sun through lenses, glasses and other human contraptions.
There even used to be a death penalty on sun gazing back in the days; you have to stop and ask yourself why the people at the top are so hellbent on preventing it. But then who will buy all the useless protection-gadgets, and pay for the useless certifications, I hear you ask; not my problem.
Has to involve nasty chemicals, radiation and flesh-cutting if it's going to work. Because, erm, that's what the profiteering psychos running this world are saying.
Is that the best you're capable of? Have you actually seen people in cancer "treatment"? What about your brain, what are you using it for instead?
I'm sorry to hear that; if you let them in there with their gadgets; they will find a reason to cut, medicate and radiate; that's unfortunately just the way things are. These are not the only options, not even the best options, for patients. Get a second opinion, and a third; preferably from outside of Big Pharma. You might have to make some tough lifestyle choices; like seriously cutting down on meat, alcohol, sugar and stress; but your body has an unlimited potential to heal itself when given the chance. Be well and don't panic; remember, mind over matter; how you feel will affect the outcome more than anything they could come up with.
If multi-platform is your biggest problem, I can see how that helps. I don't really care that much myself as long as my code compiles on the unixes. I sadly agree that static linking is a pain in the behind in C/C++ land. Still, the language I'm using interacts with the way I'm thinking; if that part isn't working out, all the features in the world isn't going to help.
Would you mind explaining more what that would buy us? Because I can't see it from here. Snackis uses email as a dumb transport; it doesn't even bother with headers that much since most content is encrypted; it's quite possible that other protocols will be added down the line.
I would argue that writing it in C++ would have gotten you there faster, assuming a decent level of experience with the language. There's no ecosystem in the world that beats seamless integration with C and no language that even comes close to being as pragmatic.
But I can, and I do; that's still too much noise for me. I'm sure the code is fine by Rust standards, but to me it looks like Perl with control issues. I don't need any help from my programming language with micromanaging the code I write or the way I write it. I'll ask when I want assistance, and until then I prefer if they stay the hell out of my way. I won't claim to write bug-free software; the only way to write bug-free software is to not write it at all; spending half my energy on sweet talking a psychotic compiler around every single detail is a perfect recipe for missing the bigger picture and ending up solving the wrong problems.
But that has nothing to do with Rust; this post and others is more or less claiming between the lines that the only thing that can save us from buggy software is the Rust way, which is bullshit. It didn't work for Java, or Erlang or Haskell; and it won't work for Rust; simply because the solution is experience, not more rules.
I introduced myself to TDD/eXtreme programming long before anyone was talking about it, read all the books and preached the ideas. Since then I've had the misfortune of seeing several fucked up interpretations in the wild, from hip-shooting startups to ISO-certified Scrum shops; and they all manage to miss the entire point of the exercise; which is applying common sense; distributing authority and focusing on the important parts, not least creativity. Agile is kind of like the Jet Kune Do or Ving Tsun of software development; since it contains almost no form in itself; it's very easy embrace and extend into whatever you fancy, and therefore very easy to corrupt.
Rust still means too much ceremony; there is a line where specifying more details makes the whole thing more difficult to understand and maintain; and that's still besides taking more time to write in the first place. Not everyone is into checking all the boxes, all the time; for good reasons; otherwise we'd all be coding Ada by now. Trying to shame others into adopting that mindset can only cause more division.