Oluseyi

Members
  • Content count

    20667
  • Joined

  • Last visited

Community Reputation

2116 Excellent

About Oluseyi

  • Rank
    Contributor

Personal Information

Social

  • Twitter
    oluseyisonaiya
  • Github
    oluseyi
  1. What laptop should I buy as a developer?

    What platform are your users going to be on? That will determine which machine/OS you should buy. For instance, if you wish to make games for Steam on Windows PC, then you should get a Windows PC laptop. On the other hand, if you want to release your games on iOS, you'll want a Mac. If you're targeting Android, then either Windows or Mac will suffice.
  2. Yes, Smalltalk offered something kind of like that, albeit by having an elaborate runtime that allowed you to suspend the running state of a program execution environment, editor and debugger, shut down the computer, and later restore it in full. I want that level of robustness during development, but then aggressive optimization that can strip out all debug hooks for when the code is ready to deploy. I don't disagree. In any case, I see interpretation and compilation as points along a continuum of program execution models. I, also, would love blazing fast compilers, but would not be as concerned if I could lazily compile (and recompile) objects as necessary to bootstrap my program in an interactive, editable mode. We'll get there, eventually. I haven't used Visual C++ in years, and I do miss edit-and-continue. My current build tools (clang, g++, swiftc, rustc) don't offer it, AFAICT.
  3. Don't be disingenuous. You, as a downstream developer, are not authoring C++ programs to run in a browser today—and arguably never did, WildTangent notwithstanding. The existence of browser plugin architecture didn't lead to a profusion of application developers creating their own custom plugins. (I'll point out as an aside that, technically, writing a plugin in C++ isn't "writing a C++ program in a browser" anyway, but rather writing a native application that has its I/O bridged to the web page by the proprietary browser interface. It is abundantly clear from my context, and my inclusion of a link to WASM, that I wasn't referring to this sort of tortuous interoperability.) Even with Flash, as in your video example, web developers bound their Flash objects to the rest of their pages using… JavaScript. For fully Flash games and RIAs (remember those?), they used ActionScript, an ECMAScript variant.
  4. First off, that's not how JavaScript compilation works today: https://arstechnica.com/information-technology/2014/05/apple-integrates-llvm-compiler-to-boost-webkit-javascript-performance/ https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ Modern JavaScript compilation in WebKit (I believe Google's V8 has something similar) has four stages of compilation, essentially live-profiling invocations of functions and pushing for the next tier of compilation/optimization when certain thresholds are crossed. The fourth stage in WebKit uses the same LLVM compiler back-end that powers the clang C++ compiler, swiftc Swift compiler, rustc Rust compiler and others. Secondly, as pointed out by @ericrrichards22, typing proceeds along two orthogonal axes which we may label static and strong. Some "statically" typed languages, like C, are nevertheless weakly typed, permitting easy type coercion and often automatically/silently promoting them, with subtle errors—even with more stringent compiler flags enabled. Python and JavaScript are strongly typed languages, with zero coercion, but are dynamically typed in that they allow rebinding objects of different types against variables and elide type constraints on function signatures. A language like Rust shows that static typing is not absolute, as it permits rebinding against the same variable name as long as it can infer static type, but mandates type constraints (and lifetimes!) on function calls. None of these are interesting questions. Instead, ask: whether it can efficiently be deployed to the target environment (no point writing a C++ program to run in the browser—yet); whether the program can maintain the invariants required by the specification; and what the median operational complexity and upper-bound cost of execution are. As a developer, I wish every language offered both interpretation and compilation, so that I could model and explore the problem space and debug my solution interactively, and then compile with full optimizations for production deployment. I believe that is eventually where we'll end up, rendering this "debate" moot once and for all.
  5. This isn't true. First of all, JavaScript was created as work-for-hire, with Eich working for Netscape Communications. What he wrote in 10 days was merely a prototype; the beta didn't ship until four months later. It was submitted for standardization by ECMA the following year. None of this was driven by the personal agenda of Mr. Eich; Netscape Communications and Microsoft were the prime movers at this time. You've allowed your personal objections to Mr. Eich to make you vulnerable to massive historical distortion, and then based an ostensibly technical dissatisfaction on said distortion.
  6. JavaScript is routinely compiled these days, with various levels of optimization triggered by access frequency and invocation history. This has been a big part of the performance improvements of Google's V8 and Apple's Nitro, especially on mobile. Your argument is poor, and takes a single socio-political position as justification to demean and dismiss the entirety of someone's technological contribution. Don't do that; that's zealotry, too.
  7. Been good, thanks! How are you? It's an interesting idea, but I recently learned that mere shared use of LLVM does not mean that the languages built with it are inherently link-able. Specifically, Rust and Swift both use LLVM as their back-end, but their object models are different enough that engineering the type transparency, etc is a significant lift. Most efforts at commingling the two, for now, focus on using C FFI as a narrow aperture for invocations. Pity.
  8. Image Processing Server

    For real-time processing, the delivery guarantees of HTTP (delivery receipt, retries) are an overhead you might not want. UDP does, superficially, seem like the way to go.
  9. Languages don't really make you a better programmer, concepts, techniques and algorithms do. Different languages are a proxy for this, as they bundle up opinionated implementations of a selection of concepts, techniques and algorithms. What you want to look for are different languages that espouse complimentary sets of concepts and techniques, and solve challenging problems using similar algorithms in them—so that you get a sense for how different languages (again, as proxies for concepts and techniques) occasion different implementation strategies. Good question, though.
  10. Hey guys, long time no post! Funny sequence of events that led to me checking in today. My take: nothing will ever "replace" C++, because nothing will ever have the same degree of critical mass/hegemony that C had and C++ inherited. The language ecosystem will be more diverse and varied, with individual languages and their code being more generally portable, and practitioners more able to switch toolsets because the norm today is to have high-quality, cost-free, often open sourced implementations. My other (and hotter!) take: JavaScript already "replaced" C++ as the language in which the largest subset of user-facing applications, and even server-side infrastructure, is written in.
  11. Should I drop pygame?

      Stick with PyGame. There is a tremendous amount of value in learning to solve problems in your given environment. There is also a tremendous amount of value in learning how to iteratively prototype and develop in languages like Python that offer a REPL (Read-Evaluate-Print Loop). Thirdly, there is a tremendous amount of value in learning different approaches/techniques embodied by different languages. A language like Python is deeply, trivially introspective, whereas a language like C# requires more elaborate reflection libraries to approximate the same; or Python's structural flexibility and preference for composition over inheritance versus C#'s object orientation orthodoxy. Over the course of your studies and, should you continue to pursue this professionally, career, you will need to work with and learn many different languages. Completing reasonably complex projects in different languages is a great way to build competence. Finish your current project in PyGame, then reevaluate and see if you want to move to Unity or something else for your next project. Good luck!
  12. How to encode h264 video

      I did exactly this using what is now libav for MPEG/H.264 encoding 5+ years ago. What encoder are you using, @amtri, x264?
  13.   Ah, I see what you mean. Is this a 2D strip or a full 3D "tube"? I'll tackle the 2D solution now, and then we can extrapolate to 3D as necessary.   The key is that the red points define a line through the center of your strip, and that at each joint the red point is the center of a cross-cutting line whose adjacent angle is precisely half the deflection between the segments. So, starting from the left of your diagram and numbering the red points p1, p2, p3 and p4: at p1 there is no previous segment, so our strip's ends are perpendicular to the vector <p2 - p1>; at p2 the cross section is at an angle relative to <p2 - p1> that is precisely half the angle between <p2 - p1> and <p2 - p3>; at p3 we have no next segment, so our strip's ends are again perpendicular to the vector, this tome <p3 - p2>. Remember that perpendicular lines have slopes that are the negatives of each other.   Using the above, you should be able to generate the points in your strip. Be careful in your algorithm to maintain the correct vertex order. I'll check back in a couple of days to see how you made out.
  14. Pygame - time and movement issues

    Unfortunately I can't run your demo because PyGame on OS X relies on X11, which I won't install, and my Linux box is temporarily out of commission. Nevertheless, I know what your problem is.     In your main loop, you do two things. You update the player position: player_pos[0] += player_speed player_rect.center = player_pos and you update the frame time, setting an upper bound on refresh frequency: frame_duration = clock.tick(FPS) # 1 frame -> ca. 16 milsecs The former assumes that frame_duration is constant, so it uses a constant increment for player position. The latter obtains the actual duration of the frame, which the PyGame docs tell us: "Note that this function uses SDL_Delay function which is not accurate on every platform…"   Your problem is that you are applying what you think is a constant displacement per constant time, yielding constant velocity, but in actuality your time is variable, making your velocity variable. To smooth it out, normalize your displacement by your actual frame time: FPS = 60 player_speed = 0.8 # pixels per frame basis_frame_time = 1.0 / FPS while 1: # ... frame_duration = clock.tick(FPS) frame_displacement = player_speed * (frame_duration / basis_frame_time) player_pos[0] += frame_displacement #... That should do it.
  15.   The fate of these causes is never "decided," anywhere. Change is individual, aggregated. That's why discussion about them is so important: because it's the vector for that individual change.         The rules are the rules. I shall abide them.